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Preface 


This book is a self-instruction course in how to design and animate screen 
images on the ATARI Computer. The book centers around what is called 
"Player-Missile Graphics (PMG)". 

The course will take you step-by-step through all of the fundamentals of 
PMG and give you "progress checks" so that you can check your understand¬ 
ing of the material presented. When you see a black square in the margin (like 
this ■{, you will know I am about to ask you a question. Since the correct 
answer is given immediately below the question, you may wish to cover it up 
with a separate sheet of paper before you continue reading. 

You will get the most from this book if you answer each question and 
then compare your response with the one given. If your answer is incorrect, I 
suggest you reread the material preceding the question and then answer it 
again. When you're sure you understand, go on to the next section. 

Most chapters end with a sample program. I suggest you enter each 
program and save it under a unique name. Successive programs build on the 
previous ones, so when preparing a new program, first enter the one you 
typed in previously and then modify it. 

Have fun! The programs all work. The one in Chapter 11 is quite involved 
and may contain some hidden bugs. I invite your help. If you find any bugs or 
come up with improvements, I would be delighted to hear from you. Write to 
me in care of Reston Publishing Company, Inc., Reston, Virginia. 




Contents 


Chapter 1: Introducing PM G, 1 

Easy Image Creation, I 
Extra Colors, 1 

Three-Dimensional Effects, 2 
Animation, 2 
Not Just for Games, 2 
Learning to Use PMG, 2 
Overview of PMG Setup, 3 

Chapter 2: Designing Player Images, 5 

How Images are Stored, 6 
One- and Two-Dimensional Images, 7 
Designing a Player Image, 8 
Lighting Up Pixels, 10 

Converting the Image to Decimal Numbers, 15 
More Practice, 16 

Chapter 3: Dimensioning Strings for PMG, 19 

Dimensioning Strings for PMG, 19 

The Buffer String, 20 

IK Boundary, 21 

Starting on a IK Boundary, 22 

Understanding the Filler Code, 22 

Setting Up PM Memory, 24 

Player Numbering, 25 



<ii / Contents 


Chapter 4: Getting a Player on the Screen, 27 

Main Programming Tasks, 27 
PM BASE, 35 
HPOSPO, 40 
Trying It Out, 42 
An Assignment, 45 

Chapter 5: Animating Your Player, 47 

Animation Without a Joystick, 47 
Joystick Control, 51 
Modifying the Program, 53 
Setting Display Priorities, 55 
Changing Speed, 58 
Looking at PM Data, 61 

Chapter 6: Making Your Player Dance, 65 

Defining Images, 65 
Initializing the Image Strings, 67 
An Experiment, 69 
Trapping Errors, 73 

Chapter 7: Adding Sound, 77 

The Sound Statement, 77 
Chords, 79 

Poking Sound Parms, 80 
Sound Registers, 81 
More Experiments, 81 
Using a Loop, 83 
Using Pokes, 84 
Adding Variety, 85 

Chapter 8: Missiles, 89 

Defining the Missile Image, 89 
Horizontal Position Register, 92 
Revising the Main Loop, 92 
Building a Missile Move Routine, 93 
Error Routine, 101 
Missile Size Register, 103 
Complete Listing, 105 



Contents / 


Chapter 9: Single-line Resolution, 109 

Line 11000, 109 
Line 11010, 110 

Lines 11020 through 11040, 110 

Lines 11045 and 11047, 110 

Lines 11070 and 11330, 110 

Line 11085, 111 

Lines 5 through 14, 111 

Line 10070, 111 

Line 315, 111 

Lines 3000 through 3080, 112 

Chapter 10: Detecting Collisions, 117 

Collision Detection Registers, 117 
Assigning Variable Names, 118 
Reading Collision Registers, 119 
Multiple Collisions, 120 
Clearing Collision Registers, 120 
Using Collision Registers, 121 
Drawing a Playfield, 121 
Revising the Main Loop, 122 
Player-Playfield Collisions, 123 
Missile Collisions, 125 
Tiy It, 126 

Slow Player Movement, 131 
Adding More Features, 132 

Chapter 11: Programming a Game, 135 

Mazeduel, 135 
Checking for Collisions, 137 
Moving Legs, 138 
Crystal Defense System, 139 
Missile Move Routine, 139 
Typing in the Program, 141 

Chapter 12: Odds and Ends, 153 

Five Playersl, 153 
Multicolored Players, 155 
Graphic Shape Registers, 155 



/ Contents 


DMACTL, 156 
Sample Program, 157 


Appendix, 163 



ATARI® Player-Missile Graphics 





Introducing PMG 


Surprise! Atari has a secret feature that sets it apart from most other personal 
computers. It's called Player-Missile Graphics (PMG for short). With PMG you 
can create all sorts of special graphic effects—effects that would be extremely 
difficult, if not impossible, with an Apple, IBM, or TRS-80. 


EASY IMAGE CREATION 

Once you know how, you can easily create your own "custom made" graphic 
images. Thanks to Atari's special direct memory access system (DMA), it's 
almost as easy as shading in squares on a piece of graph paper. 


EXTRA COLORS 

You can make your "babies" any color you want. These images (or "players," 
as Atari calls them) are independent of the usual screen images. Let's say you 
are using what is called "graphics mode 5." Normally, with this mode, you are 
limited to four colors. But with PMG you can have up to nine colors, because 
each player can be a different color. 



2 / Introducing PMG 


THREE-DIMENSIONAL EFFECTS 

PMG lets you simulate 3-D. Because players are independent of the other screen 
images, they can be set to hide behind (or go in front of) other objects. Also, it's 
really easy to change the size of a player and to make a player look like it is 
moving from a distant location into the foreground. Atari uses this technique 
effectively in STAR RAIDERS to animate the attacking spacecrafts. So can youl 


ANIMATION 

PMG greatly simplifies animation. With PMG you can move players quickly and 
smoothly with just a few commands. At the same time you can simultaneously 
create sound effects and carry out other processing. That's because PMG is 
controlled by two extra microprocessors called ANTIC and CTIA (or GTIA). 


NOT JUST FOR GAMES 

Atari first developed PMG to simplify game programming. But you can use 
PMG anywhere that animation or special screen images and colors are useful. 
For example, in an educational program you could grab the learner's attention 
with an animated arrow. The arrow could point out various parts of a diagram. 
In a music program you could use players for notes and have them dance 
across the screen along with the music. In a program that displays textual 
material, you could use players to highlight important words or sentences. 
Normally this is not so easy. Without PMG, graphic images cannot appear on 
the same line with text. 

PMG could be useful in business programs, too. For example, you could 
design an animated warning routine to catch an operator's attention when a 
crucial entry was required. It might even make the job more fun and cut down 
on data entry errors. 

LEARNING TO USE PMG 

You may be saying to yourself: "If PMG is so great, why aren't more people 
using it?" Well for one reason, it has been really hard to learn—that is, up until 
now. PMG is perhaps the most powerful, yet least understood, feature of the 
Atari computer. 

But relax. In this book we will take you step by step through everything 
you need to know to create sophisticated graphic effects far beyond the reach 
of most other micros. 
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OVERVIEW OF PMG SETUP 

Here are the major programming tasks needed to set up PMG. (Don't try to 
understand all this right now. It'sjust an overview. Details will come later.) 

• Design the graphic images you want to display. Then calculate the 
data needed in memory to produce these images. 

• Allocate space in memory for PMG. 

• Dimension strings that will hold player image data. 

• Set the PMG memory to zero data. 

• Read the player image into the player image strings. 

• Set the color of the players. 

• Tell Atari where the PMG memory starts. 

• Tell Atari whether you want single- or double-line resolution. 

• Turn on PMG. 

• Set the initial position coordinates for players and missiles. 

• Animate the players and missiles as desired. 

These are the basic things you'll need to get started. I'll cover them first. 
Then after you've mastered them I'll show you some advanced programming 
tricks you can amaze your friends with. "How did you do that?" they'll say. 
Now, let's get started with the first task—designing player images. 




Designing 
Player Images 


In this chapter you'll learn how to design an original graphic image that you 
can animate using Atari's special PMG features. We'll call this image a "player" 
to distinguish it from other graphic objects that may appear on the screen. 
Specifically, when you finish this chapter, you'll be able to: 

1. Lay out a player image on graph paper. 

2. Figure out the binary data required in memory to create a player. 

3. Calculate the decimal numbers needed to create a player image. 

4. Sketch out the player images that would be created by various kinds of 
data in memory. 

5. Explain what distinguishes player-missile (PM) memory from ordinary 
memory. 

Let's begin by taking a look at the way graphic images are stored in 
memory. 
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HOW IMAGES ARE STORED 

As you probably know, your Atari has several different graphics modes. In this 
discussion, I will be referring to graphics modes 3 through 8. These modes are 
for displaying pictures rather than words or letters. 

An important graphics term is pixel, short for "picture cell." (Think of 
"pic.-cell.") A pixel is the smallest picture element possible. The size of a pixel 
depends on the graphics mode you are in. This next illustration shows the 
approximate size of a pixel in graphics mode 3. 



PIKEL 


If you'd like to see what a pixel actually looks like in different modes, 
trying running this program: 

10 GRAPHICS 5:? "WHAT GRAPHICS MODE WO 
ULD YOU LIKE? ...(ENTER A NUMBER BETWE 
EN 3 AND 8)" 

20 INPUT GMtIF GM<3 OR GM>8 THEN 10 
30 GRAPHICS GM 
40 COLOR 3 
50 PLOT 30,18 

60 ? "THIS IS A PIXEL IN GRAPHICS MODE 
"; GM 

70 FOR PAUSE=1 TO 1000:NEXT PAUSE 
80 GOTO 10 


As you may know, all data in random access memory (RAM) is stored in 
consecutive memory locations called bits. (Eight consecutive bits are called a 
byte.) Each bit contains either a one or a zero. 
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A certain part of RAM is used to hold data that will be used to display 
screen images. Let's call that screen RAM. If a bit in screen RAM is set to one, 
then the corresponding screen pixel will light up. If a bit is a zero, then the pixel 
will be turned off. 

■ Suppose a byte (eight bits) contains these values: 00011000. Which of these 
diagrams correctly shows the screen image that would be displayed by 
that byte? 

A. - 






ANSWER 

A (Remember that each bit set to one causes the corresponding screen 
pixel to be illuminated.) 


ONE- AND TWO-DIMENSIONAL 
IMAGES 

Notice that image "A" above is not yet really a two-dimensional image. It has a 
horizontal dimension, but no vertical dimension. Actually, it is just a stubby line. 
Let's make it into a two-dimensional image by turning on some pixels directly 
beneath it on lines two and three. 


LIME 2 
LIME 3 


Now we have a two-dimensional image. It has height and width. In 
ordinary RAM it would be hard to display this image. We would have to do a 
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lot of calculating to figure out which bits in RAM to set to one. Why? Well, RAM 
is linear; it consists of a series of bytes laid end to end. It is one-dimensional. 


RAM 


ONE DIMENSION -> 


On the other hand, screen images are two-dimensional. They have a 
horizontal and a vertical dimension. Fortunately, the Atari engineers simplified 


t 


HORIZONTAL 


VERTICAL 


all this. They arranged for the second byte in PM memory to be displayed 
directly under the image of the first byte. Similarly, the third byte is displayed 
directly under the image of the second byte, and so on. This way the data for 
an image can be stored in consecutive bytes in RAM as illustrated here: 


:B¥TEi 

BVTE2 

BYTE3 






Of course, before you put any data into those consecutive bytes, you 
need to know exactly what image you want to create. So let's go over the 
procedure for designing a player image. 


DESIGNING A PLAYER IMAGE 


First, lay out a grid that is 8 columns wide with as many rows as you like up to 
128. For example, you might start with a grid that has 8 columns and 11 rows, 
like this: 
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Next, make an image by shading in selected squares on the grid. (Actu¬ 
ally, each square on your grid represents a pixel on the display screen.) Here's 
an example: 



■ In this example, how many pixels are lit up to draw the character's neck? 


Just one. 


ANSWER 
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LIGHTING UP PIXELS 


The next step is to figure out which bits in memory to set to one so the proper 
pixels are turned on. This is really quite simple. All we do is convert each row in 
our grid to a number.. 

To do that we look at each square in our grid. If the square is shaded in, 
we write down a "one." If the square is not shaded, we write down a zero. For 
example, we would convert the first row of our player like this: 



This number—00011100—is called a binary number. Notice that it is com¬ 
posed of just ones and zeros. As you may know, a binary 00011100 is not at all 
the same as eleven thousand, one hundred (11,100). I'll explain this shortly ifyou 
don't understand binaiy numbers. For now, just remember that we are translat¬ 
ing each row of our player into a binary number. 


■ I did the first row; now you try the second and third. Convert them into 
binary numbers. 
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ANSWER 

00011100 (row 2) 

00001000 (row 3) 


■ Now would you like to do the rest? 


ooo/noo 
ooo moo 
oooo/ooo 
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ANSWER 

a. 

00011100 

g 

00011000 

b. 

00011100 

h 

00101000 

c. 

00001000 

i. 

01001100 

d. 

00011100 

J- 

01000100 

e. 

00111010 

k. 

01000100 

f. 

01011001 




Now we have all of the binary numbers needed for our player image. But 
before we can put these values into Atari's memory, we need to convert them 
into decimal numbers. That's because BASIC was designed for inputing dec¬ 
imal numbers, not binary ones. 

If you already know what decimal and binary numbers are and how to 
convert from binary to decimal, you can skip ahead to ''Converting the Image 
to Decimal Numbers." Otherwise, read on and I'll explain. 

Decimal numbers are the kind used by most normal people (You know 
what I mean—people who aren't assembly language programmers). The word 
part "dec" means "ten". For example, a decade is a period of ten years. The 
decimal number system contains ten different number symbols, which are: 

0, 1, 2, 3, 4, 5, 6, 7, 8, 9 

Similarly, the word part "bi" means "two." For example, bimonthly 
means "every two months." Binoculars are field glasses designed for use by 
two eyes. The binary number system uses only two kinds of number symbols: 
l's and 0's, 

Let's look at some binary numbers. To keep things simple, we'll start out 
with small binary numbers and put each number symbol in a box. 



represents a decimal 

"2" A 1 in this box 

represents a decimal 
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■ So a binaiy 11 represents a decimal 3 since 2 + 1 = 3. What, then, would this 
binary number represent? 



0 


L 




ANSWER 


2 (2+0=2) 


Now let's try a binary number with three number symbols. Again, we'll 
put each symbol in a box. This time, above each box, we'll show what the box 
is worth in decimal if it has a "1" in it. 


£43 £23 £13 


111 


/ 


A "1" in this box 


So this binary "111" represents a decimal 7 since 4 + 2 + 1 = 7. 

■ Got that? Let's see. Give me the decimal equivalent of each of these binary 
numbers: 


1 

1 

0 

■3 

1 

1 


1 

0 
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ANSWER 


6(4+2), 3(2+1), 2 


■ Let's take away the boxes. What is the decimal equivalent of each of these 
binaiy numbers? 


a. 101 

b. 010 

c. 001 

d. Ill 


ANSWER 


a. 5 b. 2 c. 1 


d. 7 


Now let's look at an eight-position binaiy number. We'll put the digits in 
boxes again to help you visualize the number. 


£1283 £643 £323 £163 £83 £43 £23 £13 


11111111 


This binary number is equal to 255 since: 

128+64+32+16+8+4+2+1=255 

■ Now, you try one. How much is this in decimal? (Hint: compare this one 
with the previous binaiy number.) 

£1283 £643 £323 £163 £83 £43 £23 £13 


111 

1 

1 

1 

0 

l 
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ANSWER 

253 (It is just two less than the previous example. Notice we now have a 
"0" in the "2 box" instead of a "1." 


■ How about this one? 

(1283 (643 (323 (163 (83 (43 (23 (13 


e 

0 

01 

0 

i 

O 

0 


16+4 = 


ANSWER 


20 


■ Tiy one more. 


(1283 (643 (323 (163 (83 (43 (23 (13 


0 

Q 

i 

e 

l 

e 

60 


ANSWER 


40 (32+8=40) 


CONVERTING THE IMAGE TO 
DECIMAL NUMBERS 

Now you're ready to convert your own player image to decimal numbers. 
Before you do that, however, you may wish to practice on some examples. 
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■ Here's the image we worked on earlier. I've done the first three rows for 
you. Tiy the rest if you like: 


0 0 11 I I 0 0 (4+8+16+32) 
0 0 01110 0 (16+8+4) 

0 0 0 010 0 0 ( 8 ) 
00011100 
00111010 
01011001 
00011000 
00101000 
01001100 
01000100 
01000100 


a. 

b. 

c. 

d. 

e. 

f. 

g- 

h. 


60 

28 

8 


j- 

k. 


ANSWER 


a. 28 g. 24 

t>. 28 h. 40 

c. 8 i. 76 

d. 28 j. 68 

e. 58 k. 68 

f. 89 


If you'd like more practice in calculating decimal numbers, you may wish 
to try this next one. Otherwise, on to the next chapter. I can't wait to show you 
a new, little-known method for allocating PM memory! 


MORE PRACTICE 

■ Give the decimal numbers for creating this shape: 
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ANSWER 


a. 60 (32+16+8+4) 

b. 124 (64 more than the previous row) 

c. 116 (124-8) 

d. 127 (3 more than row 2) 

e. 124 (same as row 2) 

f. 112 (12 less than row 5) 

g. 124 (same as row 2) 

h. 96 (64+32) 


Congratulations. You can now design your own player image and calcu¬ 
late the decimal numbers needed for it. Next,you learn howto reserve memory 
for your player-missile image data. 






Dimensioning Strings 
for PMG 


In this chapteryou’ll learn an important secret—one not revealed in most other 
books and articles on PMG.* The secret is to use strings to store PM (Player- 
Missile) data. [If you don't know what a string is or how to dimension it, I 
suggest you see Inside ATARI BASIC by William Carris (Reston, Va.: Reston 
Publishing Company, Inc., 1982.] 

Why is this such a big deal? Because (as I mentioned earlier) Atari has the 
ability to move string data super fast. So by using strings you can achieve fast 
vertical animation without resorting to machine language! Without using 
strings, vertical movement in BASIC is slow and jerky. 


DIMENSIONING STRINGS FOR PMG 

Using this approach, you dimension a separate string at the beginning of your 
program for each of your "players." Also, you dimension one string for the 
missile area. In dimensioning these strings, there are certain rules you must 
keep in mind. 


Td like to thank Sheldon Leemon for his excellent article on how to use strings for fast PMG 
animation: "Take Apart: Outer Space Attack." Softside Magazine. March 1982. 
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THE BUFFER STRING 

One rule is that the beginning of PM memory is not used to display graphic 
images directly. That is, data in this beginning area are not automatically 
displayed on the screen. In this book, we will call this beginning area of PM 
memory a buffer. 

If you want, you can store player image data in the buffer and then move 
it to the display area whenever you want to. Here's a diagram that shows the PM 
memory area., See if you can distinguish between the buffer and display areas. 


PLAYER 3 


PLAYER 2 

PLAYER 1 

J 128 BYTES 

PLAYER 0 


M3 M2 Ml MO 

BUFFER 


384 BYTES 


Note that this diagram shows the PM memory organization for what is 
called double-line resolution. Double-line resolution simply means that two 
lines are used to display each byte in PM memory. That is, if a bit is set to "1," 
then two pixels (one underneath the other) are lit up. We'll talk about double¬ 
line resolution in more detail later. Just remember that this diagram is for 
double-line resolution. Later we'll discuss single-line resolution (see Chapter 9). 

■ Study the diagram. Then answer these questions. 

1. How big is the buffer area at the beginning of the PM memoiy area? 

2. In double-line resolution, how many bytes are set aside for each 
player? 
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3. Where does the PM display area start? 

a. 384 bytes past the beginning of the PM memory area. 

b. At the very beginning of PM memory area. 

c. Neither a nor b. 


ANSWER 


1. 384 2. 128 


3. a 


One important rule, then, is that when using double-line resolution, you 
must have a 384-byte buffer at the beginning of the PM memory area. This 
buffer area is not used to turn on screen pixels. That is, if a bit is set to "1" in this 
area, there will be no direct effect on what is displayed on the screen. That's 
why we say the actual PM display area starts 384 bytes after the beginning of 
the PM memory area. 

Another important rule is that when you are using double-line resolution, 
the PM memory area must start on what is called a "IK boundary." If you know 
what I mean by "IK boundary," you can skip to "Starting on a IK Boundary." 
Otherwise, read on and I'll explain. 


IK BOUNDARY 

A1K boundary is simply a location in memory that can be divided evenly by 1K 
(IK = 1024 bytes). For example, 2048 is on a IK boundary because 1024 goes into 
2048 evenly two times. 

■ Which of these are on a IK boundary? 

a. 4096 

b. 3073 

c. 3072 


ANSWER 

a and c (1024 goes into 4096 evenly four times. 1024 goes into 3072 evenly 
three times). 
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STARTING ON A IK BOUNDARY 

To get your Player-Missile Base Register (PMBASE) to start on a IK boundary, 
you need to do some calculations. That's because the first string you define 
won't automatically start at any given point in memory. There are different 
ways to find a IK boundary. The method I recommend is to dimension some 
"filler strings” to take up space until the IK boundary is reached. Here is some 
code you can use to define these "filler" strings. Take a moment to look it over. 

DIM FILLER1$(1), 

FILLER2$((INT(ADR(FILLER1$)/1024)+1) 

*1024-ADR$(D$)-1) 

Note: When typing this code into your computer, you would normally 
enter it as one continuous line. I've broken it into separate lines here to make it 
easier to read. 

You don't really need to understand this filler code. All you need to know 
is that it takes up string memory until a IK boundary is reached. But, if you like, 
I'll explain; otherwise, you can skip ahead to "Setting Up PM Memory." 


UNDERSTANDING THE FILLER CODE 

Since you're so interested in the filler code, I'll rewrite it for you in a slightly 
different way so it's easier to understand: 

10 DIM FILLER1$(1) 

20 BOUNDARY = INT(ADR(FILLER1$) / 1024+1)*1024 
30 LENGTHFILLER2 = (BOUNDARY-ADR(D$)-1 
40 DIM FILLER2$(LENGTHFILLER2) 

Let's examine this code line by line, starting with line 10: 

10 DIM FILLER1$(1) 

In line 10 we define our first filler string, which we call FILLER1S. We do this so 
we have a reference point, to know where the beginning of string memory 
starts. 

20 BOUNDARY = INT(ADR(FILLER1$) / 1024 + 1)*1024 

In line 20 we calculate the address of the next IK boundary above the 
address of FILLER1S. We do this by dividing the address of FILLER1S by 1024, 
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adding 1 and throwing away the remainder. Then we multiply that answer by 
1024. (INT "throws away the remainder." ADR gives us the address of FILLER!$.) 

Let's apply this code to a simple example. Suppose the address of 
FILLER!S is 2040. We divide 2040 by 1024 and get 1.992. We add 1 to 1.992 and 
get 2.992. We throw away the remainder (.992) and get 2. Then we multiply 2 
by 1024 to get 2048, which is the IK boundaiy above 2024. 

30 LENGTHFILLER2 = (BOUNDARY-ADR(D$)-1) 

In line 30 we simply subtract the address of FILLER!S from the IK boun¬ 
dary and then subtract 1 from that. We subtract 1 because we want FILLER2S to 
fill up space right up to (but not over) the IK boundaiy. 

We still need to find the length of our second string, namely FILLER2S. If 
we subtract the address of FILLER1S from the next IK boundary, we would get 
8, since 2048 - 2040 = 8. But to get the proper length for FILLER2S, we need to 
subtract 1 from 8 (since we want to take up space just up to the IK boundary). 
Look at this diagram: 


2048 




FILLER2S 

7 BYTES 



FILLERlS IK BOUNDARY 

Cl BYTE3 C20485 


■ Suppose that the address of FILLER! S were 2030. What would the proper 
string length be for FILLER2S? 


ANSWER 


17 (2048-2030-1=17) 


This finishes our explanation of the filler code. Now let's go on to the 
next step. 




24 / Dimensioning Strings for PMG 


SETTING UP PM MEMORY 

After dimensioning the filler strings, the next step is to allocate space for the PM 
memory by dimensioning additional strings. Let's look again at the way PM 
memory is organized so you can see what PM strings will be needed: 


PLAYER 3 


PLAYER 2 

PLAYER 1 

| 128 BYTES 

PLAYER 0 


M3 M2 Ml MO 

BUFFER 


384 BYTES 


■ Based on this diagram, which string do you think we should define first? 

a. BUFFERS 

b. MISSILESS 

c. PLAYEROS 


ANSWER 


a. BUFFERS 


It's important to determine the BUFFERS string immediately after the filler 
strings. That way the buffer will start on a IK boundary. For example: 

10 DIM FILLER1$(1), 

FILLER2$((INT(ADR(A$)/1024+1) 
*1024-ADR(FILLER1$)-1) 

20 DIM BUFFER$(384) 
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■ Actually, line 20 isn't finished yet. Can you explain why? 

ANSWER 

It's not finished because we still need to dimension strings for the missiles 
and players. 

In doing this, we use one string for all of the missiles and a separate string 
for each of the players. 

■ With this in mind, see if you can finish line 20: 

20 DIM BUFFER$(384) 


ANSWER 

20 DIM BUFFER$(384). MISSILES$(128), PLAYER1$(I28). PLAYER2$(128). 
P LAYER3S(I28) _ 

Of course, you could use different variable names, such as MS for MIS- 
SILESS, or POS for PLAYER1S, and so on. Also, notice that there is only one string 
defined for all four missiles. 

PLAYER NUMBERING 

Notice that the players are numbered from zero to three. Does that seem a little 
strange to you? (It does to me!) Actually, you can name the players any way 
you want to. This kind of naming convention is often used by assembly lan¬ 
guage programmers. It really means that PLAYERO starts 0 bytes from the 
beginning of the player area. Similarly, the name ''PLAYER1" means that the 
player is located 1*128 or 128 bytes from the beginning of the player area. 
Similarly, PLAYER2 is located 2*128 or 256 bytes from the beginning of the 
player area. 

That's quite a mouthful I know. Let's see if I got the message across: 

■ Suppose you know that the beginning of the player memoiy area starts on 
byte 4480. Where would PLAYER! start? 


ANSWER 

4608 (4480+1*128=4608) 
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■ Again, assuming the player memoiy area starts on byte 4480, where 
would PLAYER3 start in memoiy? 


ANSWER 

4864 (4480+3*128=4864) 


You now know how to allocate space for the PM memory area using 
double-line resolution. Later you'll learn how to do a similar setup for single- 
line resolution. That will be easy since you've already learned the fundamental 
concepts involved. Now that we've defined our player image and allocated 
space for PM memoiy, let's get a player on the screenl 





Getting a Player 
on the Screen 


Now that you have designed a player and have allocated space for PMG 
memory, let's see what that player looks like. 

When you finish this chapter you will be able to: 

• Write the code needed to get a player on the screen. 

• Put the player anywhere you want by specifying horizontal and vertical 
coordinates. 

• Make the player any desired color. 

• Use double-line resolution. 

To start with, let's go over the main programming tasks required to get a 
player on the screen. 


MAIN PROGRAMMING TASKS 

1. Define filler strings so that the PM strings area can start on a IK 
boundary. 

2. Allocate space for the PM memory area. 


27 
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3. Set the PM memoiy area to zeros. 

4. Dimension a separate string for holding our player image data. 

5. Put our player data into that string. 

6. Specify the color of our player. 

7. Specify the location of PM memory. 

8. Specify double-line resolution. 

9. Turn on PMG. 

10. Specify the desired horizontal location of the player. 

11. Put player image into the desired vertical location. 

You have already learned to write the code for steps 1 and 2, so let's go 
on to step 3. 

Setting the PM Memory Area to Zeros 

When you run a program, the data in the string area is not automatically 
cleared out. That's why we need to explicitly set the PM memory area to zeros. 
Let's start with BUFFERS. Here's a quick way to set it to zeros: 

11020 BUFFER$=CHR$(0) 

11030 BUFFER$(384)=CHR$(0) 

11040 BUFFER$(2)=BUFFER$ 

This code may seem somewhat confusing, but rest assured—it works. 
Line 11020 sets the first byte of BUFFERS to zero. Line 11030 sets the 384th byte to 
zero. Line 11040 says "start with the second byte of BUFFERS and set all the re¬ 
maining bytes of BUFFERS to the first byte of BUFFERS." (I know, it's a mouthful.) 

As an aside, if you wanted to set all of BUFFERS to some other value be¬ 
sides zeros, all you need to do is to change line 11020. For example to set 
BUFFERS so that it has nothing but "X's," change line 11020 to read: 

11020 BUFFER$=“X” 

If you'd like to take a break from reading, you may want to enter the 
above lines and experiment with changing line 11020 to see what affect it has 
on BUFFERS. If so, I suggest you start by entering these lines: 

11010 DIM BUFFER$(384) 

11020 BUFFER$=“X” 




11030 BUFFERS(384)=CHR$(0) 
11040 BUFFER$(2)=BUFFER$ 
11050 ? BUFFERS 
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Note that in line 11020 we set the first byte of BUFFERS to "X." In line 11050 
we print BUFFERS just to see what it contains. (The question mark is short for 
"PRINT.") 

After entering the lines, type "RUN." Since all of BUFFERS has been set to 
"X," you will see this: 


xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx 

xxxx 


^_ J 


Now, change line 11020 so that it reads: 

11020 BUFFER$=CHR$(0) 

Run the program again. This time you will see a screen full of hearts. That's 
because the Atari code for a heart character is a zero. 


■ Think for a moment. Does the memory location of BUFFERS contain hearts 
or zeros? 

a. Hearts 

b. Zeros 


ANSWER 

Zeros, of coursel Remember, in memory, a bit always contains either a one 
or a zero. 
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To see the zeros in BUFFERS, try running this program: 

11060 FOR 1 = 1 to 384 
11070 ? ASC(BUFFER$(I)) 

11080 NEXT I 

Note: In line 110701 am using "ASC" to return the actual number stored in 
each byte of BUFFERS rather than displaying a character. 

Now that we have set BUFFERS to zeros, we can use it to set the rest of 
PM memory to zeros. For example, we can set the missile area to zeros like this: 

MISSILES$=BUFFER$ 

■ You try it. Assume that BUFFERS has already been set to zeros. Then, write 
the statements needed to set the entire PM memory area to zeros. (Re¬ 
member, besides BUFFERS, our PM memory area contains these strings: 
MISSILESS, PLAYER0S, PLAYER1S, PLAYER2S, PLAYER3S.) 


ANSWER 


MISSILESS=BUFFERS:PLAYEROS=BUFFERS: 

PLAYER1S=BUFFERS:PLAYER2S=BUFFER$: 

PLAYER3$=BUFFER$ 


Player Image String 

Besides dimensioning the PM memory area and setting it to zeros, we need to 
dimension a string to hold our player image data. We'll call it "IMAGE1S," 
meaning "image one for player one." As you will see later, we will want to 
have more than one image for each of our players so that we can do things like 
make their legs move. 

Dimensioning the string is easy: 

DIM IMAGE1$ 

Putting the proper data into a string is a bit harder. First, you need to 
know how to refer to specific bytes of a string. If you alredy know how to do 
that, you may wish to skip ahead to "Putting Data into IMAGE! S." 

Referencing Specific Bytes 

In Atari BASIC, you can refer to specific sections of a string variable by numbers 
in parentheses after the name of the string. The first number gives the starting 





Main Programming Tasks / 31 


byte of the section of the string you want to refer to. The second number gives 
the ending byte. For example, to refer to the first three bytes of a string called 
STORAGES, we would write: 


STORAGES Cl,35 


FIRST 

LAST 

BYTE 

BYTE 


■ How would you refer to bytes 5 through 9 of STORAGES? 


ANSWER 

STORAGE$(5,9) 

If you want to refer to a single byte, just list the number of that byte twice. 
For example, to refer to byte 5 of STORAGES, you would write: 

STORAGE$(5,5) 

■ How would you refer to byte 15 of STORAGES? 


ANSWER 


STORAGES(15,l5) 


Putting Data into IMAGE1S 

To get out player image data into the string we use a "FOR-NEXT" loop. Our 
first statement in this loop is: 

FOR 1=1 to 15 

This sets up the loop so that I is set to 1 the first time through the loop. The next 
time through the loop, I will be set to 2 and so on until I is 15. 

■ Can you guess why we need to make 15 passes through the loop? 
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ANSWER 

When we created our player, we had 15 rows in our matrix. We had a 
number for each row. These numbers will first be stored in data state¬ 
ments. Each time through the loop we will read a number and then put it 
into IMAGE1S. Since we will be adding two rows ofzeros at the top ofthe 
matrix and two rows at the bottom, we have 15 numbers altogether. 


Here is the complete loop for putting all 15 numbers into IMAGE!$: 

FOR 1 = 15:READ A : IMAGE1$(I,I) = CHR$(A):NEXT I 

Let's look at each statement separately. We've already discussed "FOR 1=15." 
The next statement is "READ A." 

READ A This simply gets a number contained in a data statement and puts it 
in variable A. 

IMAGE1S|M)=CHRS(A) This statement puts the number into successive bytes 
of IMAG El S. Note the (1,1). The first time through the loop the variable I will be 
set to 1. So the statement will be equivalent to: 

IMAGE1$(1,1 )=CHR$(A) 

This means set the first byte of IMAGE1S to the contents of variable A. The 
second time through the loop, I will be set to 2. So the statement will be 
equivalent to: 

IMAGE1$(2,2)=CHR$(A) 

■ What does this mean? 


ANSWER 

Set the second byte of IMAGE1S to the contents of A. 

Now let's talk about CHRS(A). We need this because the variable A is 
numeric. You can't put numeric data into a string directly. It has to be converted 
to string data (also referred to as character data). That's what CHRS does. It 
takes whatever number is in parentheses and gets the corresponding character, 
which can then be stored in the string. 

■ What do you think would happen if we simply wrote: 

IMAGE1$=A 
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ANSWER 


Actually Atari's syntax checking feature won't even let us enter a statement 
like this. If we try to, the word "ERROR" appears, and the "A" will be 
displayed in inverse video showing that something else probably needs to 
come after the equal sign. 


Now that we have set the PM memory area to zeros, our next step is to 
specify what color we would like our player to be. 

Specifying Player Color 

You can easily control the color of a player by putting a number into a memoiy 
location. Here are the locations for each of the players: 

Player Location 

0 704 

1 705 

2 706 

3 707 


(For your convenience these locations are also summarized in Appendix A.) 

If you use graphics modes 3, 5, or 7, then you can use the following 
numbers as a guide for designating your player's color: 


Color Number 

Gray 0 

Gold 16 

Orange 32 

Red 48 

Pink 64 

Violet 80 

Purple 96 

Blue 112 

Blue 128 

Light Blue 144 

Turquoise 160 

Blue-Green 176 

Green 192 

Yellow-Green 208 

Orange-Green 224 

Light Orange 240 
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These are starting numbers. To any given number you can add an even 
number from 0 to 14 to change the lightness of the color. For example, for a 
light green color you might add 14 to 192 and use 206 as the color number. For 
a darker green you might add, say, 4 to 192 and use 196. 

■ Would 48 give you a bright red or dark red color? 


ANSWER 


Dark 


■ What number would you use for a light red? 


ANSWER 

62 (48+14) 

You might also use 56, 58, or 60 fora light red, depending on how light a 
shade you want. Notice that when you go beyond 62, you start moving into 
pink. 

Poking the Color Number 

You can use the Poke command to specify the player's color. To specify a dark 
gold color for player 0, you might write: 

POKE 704,16 

■ Write a command to set player 2's color to dark violet. 


ANSWER 

POKE 706,80 (You might also use 82,84, or 86 for dark violet. The lower the 
number, the darker the color.) 


Specifying Start of PM Memory 

The Atari microprocessor called ANTIC automatically takes care of displaying 
PM images on the screen. But before ANTIC can do that we have to tell it 
where PM memoiy starts. To do that we simply POKE the proper address into 
location 54279. Since our PM memory area is string memory, we can use the 
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ADR function. The ADR function gives the address of the string that follows it in 
parentheses. For example: 

ADDRESS=ADR(STORAGE$) 

After this statement is executed, the variable ADDRESS will contain the starting 
address of the string area called STORAGES. 

■ Recall the structure of the PM memory area. What is the first string in the 
PM memory area? 


ANSWER 

BUFFERS (Remember this area? It's sort of a multipurpose PMG storage 
area. Data stored here does not display on the screen). 


■ How would you refer to the address in memory where BUFFERS starts? 


ANSWER 

ADR(BUFFERS) 

■ From what you've learned, see if you can write a statement to inform 
ANTIC of the location of the PM memory area. 


ANSWER 

POKE 54279,ADR(BUFFERS) (We poke the address of BUFFERS into 54279 
because the address of BUFFERS is the same as the address of the start of 
the PM memory area.) 


PMBASE 


Location 54279 is known as the Player-Missile Base Register (PMBASE). If you 
initialize a variable called PMBASE to 54279 at the beginning of the program 
like this 

PMBASE=54279 

then we can tell ANTIC where PM memory starts by writing a statement like 
this: 
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POKE PMBASE,ADR(BUFFER$) 

Did you notice how I use the word "register" above to refer to a memory lo¬ 
cation? (Player-Missile Base RegisteNocation 54279.) Remember, in data pro¬ 
cessing, a register is nothing more than a memory location dedicated to a 
specific purpose. Usually we put data into a register to control the computer's 
operation. 

Specifying Resolution 

Another important register is the one used to specify resolution. We touched on 
resolution earlier, but now let's consider it in more detail. With PMG you have 
your choice of either double- or single-line resolution. Single-line resolution 
means that when ANTIC sees a "1" in PM memory it will light up a single pixel. 

In double-line resolution, when ANTIC sees a "1" in PM memory it lights 
up two pixels. Both pixels will be right underneath each other on two separate 
lines (hence the name double-line resolution). Perhaps an illustration will help 
clarify this. Suppose you have this binaiy data in PM memory: 

00011100 

00011100 

00001000 

00011100 

00111010 

01011001 

00011000 

00111100 

00100100 

00100100 

01100110 

With single-line resolution, your player will look like this: 
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With double-line resolution, you will get a player that looks like this: 



■ Which kind of resolution gives you a more "blocky" looking character? 
Which one looks more "detailed"? 


ANSWER 

Double-line resolution results in a more "biocky" looking player. You get a 
more detailed looking figure with single-line resolution. 

■ So far we have been using double-line resolution. How many bytes per 
player does double-line resolution require? (Hint: look back at how we 
dimensioned each player.) 


ANSWER 

128 

If we were to use single-line resolution we would need twice as many 
bytes for each player because each bit in memory only lights up one pixel. 

■ How many bytes would each player need in single resolution? 


ANSWER 


256 
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Keep in mind that if we dimension our players for 128 bytes, then we 
must use double-line resolution. We can't change to single-line resolution, 
unless we change the way we dimension PM memory. Also, the filler strings 
(remember them?) must be dimensioned differently because single-line resolu¬ 
tion must start on a 2K boundary. (More on single-line resolution later.) 

■ We can ask for double-line resolution by poking location 559 with 46. 
How would you code that? 


ANSWER 

POKE 559,46 


Location 559 is called the direct memoiy access control register (DMACTL). 
It is used for more than just specifying the type of resolution. We'll talk more 
about DMACTL later. For now just note that you need to poke it with 46 to ask 
for double-line resolution. As we did before, you could use DMACTL as a 
variable in place of "559." At the beginning of the program you could write: 

DMACTL = 559 

■ What is the other statement needed to ask for double-line resolution? 


ANSWER 


POKE DMACTL.46 


Turning on PMG 

Another important register is memory location 53277, called the graphics con¬ 
trol register (GRACTL). You use GRACTL to "turn on" the PMG system. You 
have different options here. You can turn on just players, just missiles, or players 
and missiles. Here's how you do it: 


If you want: 


Then: 


Missiles only 
Players only 
Players and missiles 


POKE 53277,1 
POKE 53277,2 
POKE 53277,3 


■ Suppose you want to use players and missiles. How do you specify this 
with the GRACTL register? 
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ANSWER 


POKE 53277,3 


Using Register Abbreviations 

Ifyou want, you can also initialize the variable GRACTL to 53277 at the begin¬ 
ning of your program like this: 

GRACTL=53277 

Then, to turn on PMG with both players and missiles, you could write: 

POKE GRACTL,3 

■ Can you think of a disadvantage in doing it this way? An advantage? 

ANSWER 

It takes a little more memory to initialize GRACTL to 53277. Also, it uses up 
a variable. In Atari BASIC you are limited to 128 variables. The advantage is 
that your code is somewhat easier to read. 

Well, we're almost there. Once you have taken care of these steps you 
have completed the task of setting up PMG. Often you will need to carry out 
these steps only once, so it's a good idea to put the code needed to do this into 
a subroutine. 

Assigning Line Numbers As a rule of thumb, I suggest you assign high 
numbers to subroutines that will be performed just once or when speed is not 
critical. That's because when Atari BASIC executes a subroutine, it has to search 
for it sequentially, starting with the lower line numbers. 

■ Because the PMG setup routine will usually be done just once at the 
beginning of the program, which of these line numbers do you think 
would be most appropriate for it? 

a. 100 

b. 500 

c. 11000 


ANSWER 

c. 11000 (That way you will save the lower line numbers for routines 
where speed is important). 
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Once the setup routine is complete, all you need to do is say where you 
want the player to appear on the screen horizontally and vertically. Let's take 
the horizontal specification first, since it's the easiest. We use a set of registers 
for that—the horizontal position registers for players (HPOSPO to HPOSP3). 

HPOSPO 

HPOSPO is the horizontal position register for player 0. It is memory location 
53248. 

Here are the values you poke for various horizontal screen locations: 




50 80 120 160 200 


HORIZONTAL 

COORDINATES 


Check your understanding: 

■ Write a statement to put player 0 at the: 

1. Left edge of the screen. 

2. Right edge of the screen. 

3. Center of the screen. 
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ANSWER 


1. POKE 53248,50 

2. POKE 53248,200 

3. POKE 53248,120 


or POKE HPOS0.50 

or POKE HPOS0.200 

or POKE HPOS0.120 


■ Where do you think the horizontal position register is for: 

1. playerl 

2. player 2 

3. player 3 


ANSWER 


1. HPOSP1 =53249 |one more than 53248) 

2. HPOSP2=53250 

3. HPOSP3=53251 


Often it's handy to use a variable to specify the value to be poked into the 
horizontal position register. For example, you might use HI to designate the 
horizontal coordinate for player I. Then you would write: 

POKE 53248,HI or POKE HPOSO.H1 

More on why this is useful later. Let's now look at how you set the 
vertical position of a player. 

Vertical Position 

Atari BASIC doesn't have a vertical position register. So specifying vertical posi¬ 
tion can be a problem. But because we use string memory for PMG, it's easy to 
specify vertical position. First, set a variable like, say, "vert" to the desired value: 

VERT=30 

Then use a string command to set the player string to the data contained in the 
player image string, like so: 

PLAVER0$(VERT)=IMAGE1$ 

Remember our discussion of how string commands work? The value in 
parentheses after the string specifies the starting byte. If VERT equals, say, 30, 
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then the data in IMAGE!$ will be placed in PLAYEROS starting with the 30th 
byte. This has the effect of displaying our player at vertical position 30. 

■ If we wanted to position our player at vertical position 80, we would poke 
the image data into the 80th byte of the player string. Altogether our player 
string has 128 bytes, so how many vertical positions do we have available? 


ANSWER 

128 (since each player string has 128 bytes). 

■ Write the two statements needed to put player 1 at vertical position 80. Use 
the data contained in IMAGE!S. Use the variable VERT to specify the 80th 
byte of PLAYER1S. 


ANSWER 


VERT=80 

PLAYER1 S(VERT)=IMAGE1 S 


TRYING IT OUT 

Well that's it! Now let's put this all together and get that player on the screen. A 
complete program appears on the next page. Look it over briefly. Then read the 
comments that follow it. For your convenience, I have listed the program so 
that each line has no more than 38 characters. This way the printed listing will 
match up with your screen listing. 

Caution: Be careful in typing X0 and Y0 at lines 13000 and 13010 (and 
elsewhere in the program). "X0" is "X zero," not "XO." Notice the difference? 
The zero is more oval shaped than the letter "O." 

The zero represents player number 0. "X0" contains the horizontal posi¬ 
tion for player 0. "Y0" contains the vertical position for player 0. Of course, you 
can adopt any variable naming scheme that you want. Just be consistent. 
Don't type "Y0" one time and "YO" the next. 

Comments on Program 

This program will let you look at all the different colors that a player can be. We 
have already gone over the code in detail so I will just comment briefly on a 
few points of interest. 
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1 GOSUB 2000:REM SETUP ROUTINES 

2 GOTO 200:REM JUMP TO MAIN ROUTINE 

3 SAVE "D:onscreen.sav m : stop :rem disk 

30 

199 REM MAIN ROUTINE 

200 FOR K0L0R0=0 TO 254 STEP 2 
210 POKE 704,KOLORO 

220 ? "PLAYER COLOR NUMBER*"5KOLORO 

230 GOSUB DELAY 

240 NEXT KOLORO 

250 END 

260 REM 

270 REM 

280 REM 

290 REM 

1999 REM SETUP ROUTINES FOLLONi 

2000 GOSUB 10000:REM MISC. INITIAL¬ 
IZATION 

2005 GRAPHICS 5:REM SET GR. MODE 
BEFORE PMG SETUP.' 

2010 GOSUB 11000:REM PMG SETUP 
2015 GOSUB 12000:REM DRAM PLAZF1ELD 
2020 GOSUB 13000:REM PLAYER COLOR AND 
SCREEN POSITION 
2130 RETURN 

5000 FOR PAUSE*1 TO 500:NEXT PAUSE:RET 
URN 

10000 REM MISC. INITIALIZATION 
10050 DELAY=5000:RETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2* < <INT(AD 
R(FILLER1*)/1024)+1)*1024-ADR(FILLER1* 
>-l> 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO*(128),PLAYER1 *(128),PLAYER2*(1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)=BUFFER* 

11045 MISSILES*=BUFFER*:PLAYERO*=BUFFE 
R*:PLAYER1*=BUFFER*:PLAYER2*=BUFFER*:P 
LAYER3*=BUFFER* 

11050 DIM IMAGE1*(15) 
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11060 FOR 1=1 TD 15:READ A:IMAGE1*(1,1 
)=CHR$(A):NEXT I 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 
S 

11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PMG 
11095 RETURN 

11300 DATA 0,0,28,28,8,28,58,89,24,40, 
76,68,68,0,0, 

11999 REM DRAM PLAYFIELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT 0,20:DRAWTO 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=175:REM HORIZONTAL PLAYER 
POSITION. 

13010 Y0=73:REM OERTICAL PLAYER 
POSITION 

13020 POKE 704,0:REM INITIALIZE PLAYER 
COLOR TO ZERO 

13030 POKE 53248,XO:REM PONE HORI¬ 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=IMAGE1*:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 

Line 1: GOSUB 2000 As you can see I start the program by "calling" a 
subroutine at line 2000. The purpose of this subroutine is to take care of what 
are sometimes called "housekeeping routines." These are routines that you 
usually only need to do once at the beginning of the program. By using high 
line numbers for these setup routines, I leave space at the beginning of the 
program for the main routine. This is preferable because routines requiring 
transfer of control (GOTOs or GOSUBs) execute faster if they are placed at the 
beginning. This will become more important later when our main routine 
becomes more complex. 
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Notice that the subroutine at line 2000 calls these additional setup 
routines: 

10000 Miscellaneous Initialization 

11000 PMG Setup 

12000 Drawing of Playfield 

13000 Beginning Player Color and Screen Position 

The "playfield" referred to here is simply the screen image that the player 
moves around on. In this case, I have used a few PLOT and DRAWTO state¬ 
ments to create a simple playfield. Notice that I set the graphics mode before 
doing the PMG setup. This is important because once the PMG setup is done, 
the graphics mode should not be changed. (Actually, you could change the 
graphics mode after setting up PMG, but then you need to call the PMG setup 
routine all over again.) 

I won't go into the details of how to create playfields. For details on 
playfield creation, you may wish to refer to Designs from Your Mind with Atari 
by Tom Rowle (Reston, 1983). 

Line 2: GOTO 200 Obviously this line transfers control to line 200. But why? 
Simply because we want to jump over line 3, which is really not part of the 
program. 

Line 3: SAVE "D:ONSCREEN.SAV":STOP I use this line to save the pro¬ 
gram to disk after I've made changes to it. It's really quite handy. After I've 
finished editing the program, I just type G.3 and the program starts saving itself! 
(Atari understands that "G." is an abbreviation for "GOTO.") Notice the com¬ 
mand "STOP" at the end of line 3. This keeps the program from continuing to 
execute after it saves itself. 

Line 200 to 240 Here is where the main "activity" in the program occurs. 
Notice that I have created a loop in which successive even numbers are poked 
into location 704, which is the color control register for player 0. 


AN ASSIGNMENT 

I suggest you type the program into memory. Then save it by typing G.3. Next, 
try running it. If it doesn't work, proofread your work carefully. Watch out for 
typos! They are especially destructive when you are working with PMG. That's 
why it's important to save the program before running it. 
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Once the program is working, you may wish to try modifying it slightly. 
That's the best way to learn. For example, you might try changing the values 
following the SETCOLOR command at line 13000. If you do, notice how this 
affects the color of the playfield and the player. Or, try changing the horizontal 
and vertical position of the player. You can do that by changing the values 
assigned to X0 and Y0 in the subroutine starting at line 13000. Happy hackingl 



Animating Your Player 


So far you have learned to design a player image and carry out the necessary 
PMG setup routines needed to display it on the screen in any desired color. 
After finishing this chapteryou will be able to move your player around on the 
screen with or without joystick control. 

Animation of a player without joystick control is much easier to program, 
so let's start with that first. 


ANIMATION WITHOUT A JOYSTICK 

Once you have a PMG setup routine working, it's quite easy to produce 
different results with minor program changes. In the program in the previous 
chapter we established the position of our player with the statements "X0=175" 
and "Y0=75." We used XO to specify the horizontal position and YO to specify 
the vertical. In our new animation program, we will still use these statements to 
tell where we want the player first positioned. But after that we will set up a 
loop in which we will either increase or decrease the values in XO and YO. (We 
will use XO for the horizontal position of player 0 since "X" in mathematics 
traditionally refers to the horizontal plane. Similarly, "Y" usually refers to the 
vertical plane. So I use YO to control the vertical position of the player.) 
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Main Program Loop 

Here is the start of the main loop of our new program. 

■ As you examine this code, see if you can tell which statement puts the 
program into a never-ending loop. 

1 GOSUB 200:GOTO 190 

2 SAVE “D:MOVE.SAV”:STOP 
190 SP=1 

200 POKE 53248,X0 

220 PLAYER0$(Y0)=IMAGE1$ 

230 GOTO 230 


ANSWER 


The "GOTO" statement on line 230 puts the program into a never-ending 
loop. 


Note that because the program is looping, the horizontal and vertical 
positions of the player are constantly being set. With every pass through the 
loop we have the opportunity to change the player's position. For example, to 
move the player up the screen, all we need do is decrease the value in Y0. We 
can do this with the statement Y0=Y0-1. A better way, though, is to use the 
statement Y0=Y0-SP, where SP is a variable set to "1." This way you have more 
flexibility. You can easily set SP to a different value and the player will move 
more or less rapidly. 

■ Now, take a look at the code above for a moment and decide where we 
need to put YOYO-SP to make the player move up the screen. 


ANSWER 

To make the player move up the screen, we need to insert the statement 
somewhere between lines 200 and 230. Notice that the statement must be 
within the loop so that the value in Y0 decreases with each pass through 
the loop. 

Try it. Load the program you typed in from the previous chapter. (You did 
type it in didn't you?) Then make these changes: 
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1. Delete lines 2,3,200.210.220,230.240. and 250 

2. Change lines 1 and 13020 to read as follows: 

1 GOSUB 2000:GOTO 190 
13020 POKE 704,88 


3. Add these lines: 

2 SAVE "D:MOVE1 .SAV”:STOP 
190 SP=1 

200 POKE 53248,X0 

220 PLAYER0$(Y0)=IMAGE1$ 

225 Y0=Y0-SP 
230 GOTO 200 


Important: again, watch out that you don't confuse X0 with XO. "X0" is "X 
zero." Similarly, "Y0" is "Y zero" not YO. Remember that a zero has a different 
shape than the letter "O." 

Run the program. When you've got the player moving up and off the 
screen, continue reading below. 


Error 5 What happened when the player disappeared off the screen? You 
should have gotten Error 5: "String Length Exceeded." I'll show you how to 
handle this problem later. For now, just know that this error is to be expected 
whenever your player moves too far up or down. It happens whenever Y0 is set 
to a number less than 1 or greater than 128. That's because PLAYER0S is dimen¬ 
sioned to 128 bytes. On line 220 we are moving data into PLAYER0S at the byte 
specified by Y0. Because there is no such thing as byte 0 fora string, a value of 0 
in Y0 results in an error. 

As soon as you get Error 5, try this: Print the value in Y0. (Type ? Y0 and 
press RETURN.) You will notice that Y0 contains "0," an illegal valuel 


Horizontal Movement 

■ By now you may already know how to move the player horizontally. 
Assuming that you take out line 225, what statement would you need to 
put into the loop to make the player move horizontally across the screen 
from right to left.? 
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ANSWER 

X0=X0-SP 


Try it. First insert "REM" at the beginning of line 225 so that line 225 will 
not be executed. Then insert X0=X0-SP, as line 227. When you run the program, 
the player should move from right to left across the screen. Again, don't worry 
about the error message that occurs when the player runs off the screen. This 
time you will get Error 3: "Bad Value." The bad value this time will be a -1 in X0. 
We'll handle this problem later. 

Diagonal Movement 

Now let's try diagonal movement. First, let's position the player at the top left 
corner of the screen. We do this by changing lines 13000 and 13010 so that they 
read: 

13000 X0=52 
13010 Y0=12 

For the moment also change line 230 to "GOTO 230." When you run the 
program, the player will appear at the top left corner of the screen and just stay 
there. 

■ Now let's make him run diagonally. See if you can come up with the 
statements required to make that happen. The compare your code with 
mine. 


ANSWER 


To make the player move diagonally, change lines 225, 227, and 230 as 
follows: 

225 Y0=Y0+SP 
227 X0=X0+SP 
230 GOTO 200 


Try itl 


■ Now here's another one. Write the statements needed to move the player 
diagonally (as before). But when she reaches vertical position 45, move her 
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horizontally from left to right until she reaches horizontal position 125, at 
which point just have her stop. Write the necessary code in the space 
provided. Then try it out and debug it as necessary. It may take a bit of 
experimenting to get it to work. Finally, compare your code with mine. 


ANSWER 


Here's one way of doing it: 

200 POKE 53248,X0 

220 PLAYER0$(Y0)=IMAGE1S 

225 Y0=Y0+SP 

227 X0=X0+SP 

230 IF Y0>45 THEN Y0=45 

235 IF X0>125 THEN X0=125 

240 GOTO 200 


Note: Lines 200-227 could be combined into a single line. This would 
make the player move slightly faster. But to make these programs easier to read, 
I'm putting each statement on a separate line. 

Well, moving a player without a joystick was fairly simple. Moving her 
with a joystick is not quite so easy. 


JOYSTICK CONTROL 

To control the movement of a player with a joystick, you need to: 

• Read the joystick. 

• Figure out the position that the stick has been moved to. 

• Change the value of X0 or Y0 accordingly. 

Reading the stick is easy. For example, this statement will read joystick 0 
(the one on the far left) and put a numerical value in "S." 

S=STICK(0) 

Note: The place where you plug in joystick 0 is labeled "Controller Jack 
1." Similarly, "Controller Jack 2" is the label for the port forjoystick 1, and so on. 

This diagram shows the various numbers that will be read into "S" when 
the joystick is moved to each position. 
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11 



■ Suppose you move the joystick to the right. What will be the value of "S" 
after the statement S=STICK(0) is executed? 


ANSWER 


■ What is the value of "S" when the joystick is not moved, but left in its 
normal resting position? 


ANSWER 

15 


You can handle the values put into "S" in different ways. Here's one 
simple way: 

S=STICK(0) 

IF S=7 THEN X0=X0+SP 
IF S=11 THEN X0=X0-SP 
IF S=14 THEN Y0=Y0-SP 
IF S=13 THEN Y0=Y0+SP 
IF S=6 THEN Y0=Y0-SP:X0=X0+SP 
IF S=10 THEN Y0=Y0-SP:X0=X0-SP 
IF S=9 THEN Y0=Y0+SP:X0=X0-SP 
IF S=5 THEN Y0=Y0+SP:X0=X0+SP 
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This works. But look at all those IF-statements! They slow down program 
execution and make it difficult to get smooth and lively animation. Actually, 
you don't need to use any IF-statements at all. You don't even need the STICK 
statement.* 

For maximum speed, it's better to peek into memoiy location 632 to read 
joystick 0, like this: 

PEEK(632) 

Forjoystick 1 we would use "PEEK(633|," forjoystick 2, "PEEK(634)" and so on. 

Now, to handle the joystick value without “IF-statements," we will 
simply use a GOSUB command. A powerful feature of Atari BASIC is that you 
can use a PEEK command in combination with a GOSUB statement. 

■ Suppose you pull straight back on joystick 0. What value will be in memory 
location 632? (Look at the joystick drawing if you need to.) 


Now suppose we write this statement: 

GOSUB PEEK (632) 

■ To which subroutine will the program go if you pull back on the joystick? 


ANSWER 

It will go to the subroutine starting at line 13 (since location 632 will contain 
a 13 when the joystick is pulled backward). 


MODIFYING THE PROGRAM 

Now let's modify our program again. At line 10050 let's initialize a variable 
called "JOYSTICK" to 632. And while we're at it, let's initialize HPOSO to 53248, 


"Thanks go to that wild and wacky game programmer, Robert Sombrio, for showing me the fast 
joystick reading routine presented in this chapter. I tested it against a machine language subroutine 
published in a major magazine. Robert's routine won hands downl 
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and SP to I also at line 10050. Then we can peek into "JOYSTICK" to determine 
which subroutine to execute. Line 10050 will then read: 

10050 JOYSTICK=633: 

HPOSPO=53248: 

SP=1: 

RETURN 

Our main loop will then look like this: 

200 GOSUB PEEK(JOYSTICK): 

POKE HPOSP0.X0: 

PLAYER0$(Y0)=IMAGE1$: 

GOTO 200 

Now we also need something at lines 5,6, 7, 9,10, II, 13,14, and 15. Here 
are lines 5, 6, 7, 9, and 10: 

5 X0=X0+SP:Y0=Y0+SP: RETURN 

6 Y0=Y0-SP:X0=X0+SP:RETURN 

7 X0=X0+SP:RETURN 

9 X0=X0-SP:Y0=Y0+SP: RETURN 

10 X0=X0-SP:Y0=Y0-SP: RETURN 

■ To complete the routine, we need to add lines 11,13, and 14. See if you can 
write line 11: 


ANSWER 

11 X0=X0-SP (If the joystick is moved left, location 632 will contain 11. To 
move our player to the left, we decrease X0 by one with "X0=X0-1"). 

■ Now write the code for lines 13 and 14. (If location 632 contains 13, the 
joystick was moved down; if location 632 contains 14, the joystick was 
moved up.) 


13 Y0=Y0+SP:RETURN 

14 Y0=Y0-SP:RETURN 


ANSWER 
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■ How about line 15? If the joystick is not moved at all, location 632 will 
contain 15. In this case we don't want to change the XO or YO values at all 
but simply return from our subroutine. Given that information see if you 
can write line 15. 


To clean up the program, be sure to delete lines, 2,190, 220,225, 227, 230, 235, 
and 240 since they are not needed for joystick control. 

Also, after deleting line 190, be sure to change line 1 to: 

1 GOSUB 2000:GOTO 200 

On the next page you will find a complete listing of the program for moving a 
player under joystick control. Try it out. When you've got it running, continue 
reading and we'll make a few more changes. 

SETTING DISPLAY PRIORITIES 

Another nice feature of PMG is that you can make players hide behind certain 
playfield objects, yet come out in front of others. This is called setting display 
priorities (or often simply "picking a priority option"). When you are program¬ 
ming in BASIC, you'll use memory location 623 as the priority register.* (This 
register is also used for other purposes, but one thing at a timel) 

You can set various display priorities by poking either 1, 2, 4, or 8 into 
location 623. If you poke 1 into location 623, players will show up in front of all 
playfields. Furthermore, player 0 will appear in front of player 1, player 1 will 
appear in front of player 2, and so on. 

If you poke 2 into location 623, then players 2 and 3 will appearbehind 
all playfield objects. Players 0 and 1 will still appear in front of all playfield 
objects. 

If you poke 4 into location 623, then all playfields will appearin front of 
all players. 

If you poke 8 into location 623, then players will go behind some 
playfields and in front of others. In our sample program players will go behind 


‘Location 623, technically, is the shadow of hardware register 53275. A shadow is a RAM register 
as opposed to a ROM hardware register in an Atari chip like GTIA. Thirty times a second the 
operating system takes whatever value is in the shadow register and sticks it into the corresponding 
hardware register. 
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1 GOSUB 2000:GOTO 200 

2 SAVE "D:MQVE1.SAV":STDP :REM DISK 30 

4 REM ADJUST HORIZONTAL & VERTICAL 
COORDINATES 

5 xo-xo+sp:yo-yo+sp:RETURN 

6 yo-yo-sp:xo-xo+sp:return 

7 xo-xo+sp:return 

9 xo-xo-sp:yo-yo+sp:return 

10 xo-xo-sp:yo-yo-sp: return 
u xo-xo-sp: return 

13 YO-YO+SP:RETURN 

14 YO-YO-SP:RETURN 

15 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK(JOYSTICK):POKE HPOSPO,X 
0:PLAYERO*(YO)=IMAGE1 *:GOTO 200 

260 REM 
270 REM 
280 REM 
290 REM 

1999 REM SETUP ROUTINES FOLLON’. 

2000 GOSUB 10000:REM MI SC. INITIALI¬ 
ZATION 

2005 GRAPHICS 5:REM SET GR. MODE 
BEFORE PMG SETUP.' 

2010 GOSUB 11000:REM PMG SETUP 
2015 GOSUB 12000:REM BRAN PLAYFIELD 
2020 GOSUB 13000:REM PLAYER COLOR AND 
SCREEN POSITION 
2130 RETURN 

10000 REM MI SC. INITIALIZATION 

10050 JOYSTICK-632:HP0SP0-53248:SP-1: R 

ETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILL.ER1*(1>,FILLER2*((INT(AD 
R <FIL.LER 1 $) / 1024) +1) * 1024-ADR (FILLER1 * 
)-l) 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO* (128), PLAYER 1 * (128) , PLAYER2* (1 
28),PLAYER3*(128) 

11020 BUFFER*-CHR*<0> 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)-BUFFER* 
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11045 MISSILES$=BUFFER*:PLAYER0$=BUFFE 
R$: PLAYER1*=BUFFER*: PL.AYER2*=BUFFER$: P 
LAYER3$=BUFFER$ 

11050 DIM IMAGE1 $ <15) 

11060 FOR 1=1 TO 15:READ A:IMAGE1$(I,I 
)=CHR$(A):NEXT I 

HOBO POKE 54279,ADR(BUFFERS)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 
S 

11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PM6 
11095 RETURN 

11300 DATA 0,0,28,28,8,28,58,89,24,40, 
76,68,68,0,0 

11999 REM DRAM PLAYFIELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT 0,20:DRAWTO 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PL RYE R COLOR AND 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248,XO:REM PONE HORI¬ 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=IMAGE1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 


playfield objects drawn with color 1 or 2, but in front of objects drawn with 
color 3. 

The best way to learn to use the priority register is to experiment with it.* 
Let's modify our program to do that by making these seven changes: 


*1 am deliberately avoiding, here, the usual discussion of "playfields 0 thru 4." That's because it's 
difficult to define how a specific playfield is created using SETCOLOR, COLOR, PLOT, and 
DRAWTO statements. 
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1. Change line 1 so that it reads: 

GOSUB 4000:GOSUB 2000:GOTO 200 

2. Add this subroutine starting at line 4000: 

4000 ? “What number would you like to poke into the 
priority register?”:INPUT PR 

4020 RETURN 

3. At line 10050 set the variable PRIOR to 623. 

4. Delete the RETURN statement at line 11095. 

5. Add line 11110 as follows: 

POKE PRIOR,PR 

6. Put a RETURN at line 11299. 

7. Change line 2 to: 

SAVE “D:MOVE2.SAV”:STOP 

After making these changes save the program and then run it. Tiy poking 
different numbers (1,2,4,8) into the priority register. Then move your player in 
front of the different colored playfield objects on the screen. Make a note of the 
results. 

If you're going to take a break, now is a good time. When you come 
back, we'll discuss speed. 

CHANGING SPEED 

In some situations you may want to change the speed of a player. For example, 
in a horse race simulation, you might want to assign different speeds to the 
different horses. In a baseball game, you might want to assign various running 
speeds to different players. To do this all you need to do is set SP to different 
values. 

Experiment with Different Speeds 

To experiment with different speeds, try adding line 4010 as follows: 
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?“ENTER A NUMBER BETWEEN 1.0 AND 2.0 TO SET 
SPEED OF PLAYER.”:INPUT SP:RETURN 

Also, delete SP=1 from line 10050. Then run the program several times, 
setting SP to various numbers from 1.0 to 2.0. When you've got the player's 
speed under your control, continue reading. 

Faster Speeds 

Now try to set the player's speed even faster—to a number greater than 2.0. 

■ What happens when you move the player vertically? Horizontally? 


ANSWER 

Notice that when you move the player vertically, you leave a trail consisting 
of pieces of the playerl But when you move him horizontally, this doesn't 
happen. That's because horizontal movement is controlled by poking a 
number into the horizontal position register. Atari then takes care of erasing 
the player and repositioning him horizontally. But for vertical movement 
there is no horizontal position register, yet.* 

To move the player vertically, we have to write the player image data into 
different bytes of the player image string. Consider for a moment the data that 
we put into IMAGE1S: 

0,0,28,28,8,28,58,89,24,40,76,68,68,0,0 

■ Notice that the first two bytes of IMAGE1S contain zeros. What do the last 
two bytes contain? 


ANSWER 

They contain zeros also. 


*1 suspect that when Atari updates its PMG system, a vertical position register will be added. After 
all, the Commodore 64 has onel In the meantime, we have to manage with other means to move 
our players vertically. 
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These zeros serve the purpose of automatically erasing the player image 
as we move it around within PLAYEROS. Let's look at some specific examples. 
Suppose we position the player near the bottom of the screen at vertical 
position 80. To do this we might use these commands: 

Y0=80: PLAYER0$(Y0) = IMAGE1$ 

The diagram below shows what will be in each byte of PLAYEROS: 


Byte Contents 

1 0 

2 0 

3 0 


(and so on) 

80 0 

81 0 

82 28 

83 28 

84 8 

85 28 

86 28 

87 89 PLAYER IMAGE DATA 

88 24 

89 40 

90 76 

91 68 

92 68 

93 0 

94 0 

Notice that our player image data is located at bytes 80 thru 94. Now 
suppose we want to move our player upward by one byte. To do this we need 
to move all 15 bytes upward. For example, the value 76 in byte 90 will be 
moved up so that byte 89 will contain 76. 


■ Consider byte 92. Before we move the player, byte 92 contains 68. This is 
the data for the bottom of the player (his feet). When we move the player 
image data up one byte, what will be in byte 92? 
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ANSWER 

A zero! This is important. As we move the player data up, the player erases 
himself. 


Since we have two zeros at the beginning of IMAGE1S and two at the 
end, we can move the data in one or two byte increments and the "trailing 
zeros" will automatically erase the player image. 

■ We can still move the player vertically in three byte increments. But we will 
need to change IMAGE!S. What changes would we need to make? 


ANSWER 

We would need to dimension IMAGEIS for 17 bytes. Then we would need 
to make bytes 1-3 and bytes 15-17 zeros. IMAGEIS would then contain this 
data: 

0,0,0,28,28,8,28,58,89,24,40,76,68,68,0,0,0 


To make this change, we would need to change line 11300, so the data 
matches that given above. We would also need to change line 11050 so that it 
reads: 


11050 DIM IMAGE$(17) 

And line 11060 should be: 

11060 FOR 1 = 1 TO 17: 

READ A: 

IMAGE1$(I,I)=CHR$(A): 

NEXT I 

Make those changes. Then try setting SP to 3. Your player will now erase 
himself completely as he moves vertically at a speed of 3 bytes per movel 


LOOKING AT PM DATA 

To get a better idea of how PM data is stored in PLAYER0S, try this. Move the 
player to some vertical position of interest. Then press the SYSTEM RESET key. 
Next type in and run the following routine. You can run the routine simply by 
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typing “GOTO 600,"' and pressing RETURN. The routine will show you the 
contents of PLAYEROS byte by byte. To temporarily halt the routine, hold down 
the CONTROL key and press "1." Do the same to restart it. 

600 GR.0:TRAP 610: FOR 1=1 to 128: 

? I;“ “;ASC (PLAYER0$(l)): 

NEXT l:STOP 

610 END 

Well, we've come a long way. But there is still a lot to learn about PMGI 
For one thing, although our player moves around the screen at our command, 
she looks funny because her legs don't movel In the next chapter you'll learn 
how to fix that. 

For your convenience at the end of this chapter is a complete listing of 
the program. It's set up so you can choose the value to poke into the priority 
register. You can also choose the value for SP, which determines the speed of 
the player. 


1 BOSUB 4000:GOBUB 2000:GOTO 200 

2 SAVE "D:MOVE2.SAV":STOP :REM DISK 30 

4 REM ADJUST HORIZONTAL Sr VERTICAL 
COORDINATES 

5 XO=XO+SP:YO=YO+SP:RETURN 

6 yo«yo-sp:xo=xo+sp:return 

7 xo=xo+sp:return 

9 xo»xo-sp:yo=yo+sp:return 

10 xo=xo-sp:yo=yo-sp:return 

11 xo=xo— sp:return 

13 yo=yo+sp:return 

14 YO=YO-SP:return 

15 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK (JOYSTICK) : POKE HPOSF'O, X 
0: F'LAYERO* (YO) = I MAGE 1 *: GOTO 200 

260 REM 
270 REM 
280 REM 
290 REM 

600 GRAPHICS 0:TRAP 610:FOR 1=1 TO 128 
:? ij" ";ASC(PLAYERO*(i )):next i:stop 
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610 END 

1999 REM SETUP ROUTINES POLL ON '• 

2000 GOSUB 10000:REM MI SC. INIT1ALI- 
IATION 

2005 GRAPHICS 5:REM SET GR. MODE 

BEFORE PMG SETUPf 

2010 GOSUB 11000:REM PMG SETUP 

2015 GOSUB 12000:REM DRAM PLAYFIELD 

2020 GOSUB 13000:REM PLAYER COLOR AND 

SCREEN POSITION 

2130 RETURN 

4000 ? "WHAT NUMBER WOULD YOU LIKE TO 
POKE INTO THE PRIORITY REGISTER?":I 
NPUT PR 

4010 ? "WHAT SPEED WOULD YOU LIKE FOR 
THE PLAYER? 1, 2, OR 3?":INPUT SP 

10000 REM MI SC. INITIALIZATION 

10050 J0YSTICK=632:HP0SP0=53248:PRIOR* 

623:RETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2*((INT(AD 
R(FILLERl*)/1024)+1)*1024-ADR(FILLER14 
) - 1 ) 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO*(128),PLAYER1*(128),PLAYER2*(1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)=BUFFER* 

11045 MISSILES*=BUFFER*:PLAYERO*=BUFFE 
R*: PLAYER 1 *=BUFFER*: PLAYER2*=BLJFFER*: P 
LAYER3*=BUFFER* 

11050 DIM IMAGE1*(17) 

11060 FOR 1 = 1 TO 17:READ A: IMAGE1 *(I, I 
)=CHR*(A):NEXT I 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 
S 

11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PMG 
11110 POKE PRIOR,PR 
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11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11999 REM DRAM PLAYFIELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT 0,20:DRAWT0 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248,XO:REM POKE HORI¬ 
ZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*<Y0>=IMAGE1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. VO 
DETERMINES VERTICAL POSITION 
13050 RETURN 



Making Your Player 
Dance 


Next you will learn how to add life to your player by making his or her legs 
move. You'll also be able to create other kinds of movements as desired. In 
addition, you'll learn how to take care of those troublesome errors that occur 
when you move a player too far off the screen. 

Let's start by animating those legs. 


DEFINING IMAGES 


To make our player's legs move, we need to define three player images, which 
we will call "LEGSIS, LEGS2S, and LEGS3S." 

Here's the first image for our player along with the data needed to create 
her. (Notice that we have omitted the leading and trailing zeros.) 
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ANSWER 

28.28,8.28,58,89,24.56,72,132,130 


INITIALIZING THE IMAGE STRINGS 

Now that we've designed the images, we need to initialize our player image 
strings. Remember how we do it? To initialize our first image, we use a line like 
this: 

11060 FOR 1=1 TO 17:READ A: 

LEGS1$(I,I)=CHR$(A):NEXT I 

■ The data for this will appear on line 11300 like this: 

11300 DATA 0,0,0,28,28,8,28,58,89,24,60,36,36,102,0,0,0 



■ Why did we do that? 
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ANSWER 

So the player will erase herself when we move her up or down. By using 
three leading and trailing zeros we can bump the player up three bytes 
and still get a clean erase. 


Now to initialize our second image we simply insert line 11065, which is 
almost identical to line 11060: 

11065 FOR 1=1 TO 17:READ A: 

LEGS2$(I,I)=CHR$(A):NEXT I 

Of course we also need to add the data for LEGS2S. We do that on line 11310: 
11310 DATA 0,0,0,28,28,8,28,58,89, 

24,40,76,68,68,0,0,0 


■ Your turn again. Write the lines needed to initialize the third player image. 
Ill supply the line numbers. 

11067 

11320 


ANSWER 


11067 FOR 1=1 to 17:READ A: 
LEGS3S |I,I)=CHRS(A): 

NEXT I 

11320 DATA 0,0,0,28,28,8,28.58.89, 
24,56,72,132,130,0,0,0 


Oh yes, another thing. We need to dimension our new strings. We can 
easily do this on line 11050: 

11050 DIM LEGS1$(17), LEGS2$ (17), LEGS3$(17) 


■ That takes care of setting up the image strings. Next we need to set up a 
routine to move these images into the PM memory area. Specifically, we 
will want to move them into which string? 
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ANSWER 


We'll want to move the data into PlayerOS, which is the PM memory area 
for PLAYERO. 


AIM EXPERIMEIMT 


First, enter the last program from the previous chapter into memory. Then make 
these changes: 

1. Delete lines 4000 through 4020 and remove GOSUB 4000 from line 1. 

2. Change line 11050 so it reads: 

11050 DIM LEGS1$(17), LEGS2$ (17), LEGS3$ (17) 

3. Add lines 11060,11065, and 11067: 

11060 FOR 1 = 1 to 17:READ A: 

LEGS1$ (l,l)=CHR$(A): 

NEXT I 

11065 FOR 1 = 1 to 17:READ A: 

LEGS2$ (l,l)=CHR$(A): 

NEXT I 

11067 FOR 1 = 1 to 17:READ A: 

LEGS3$ (l,l)=CHR$(A): 

NEXT I 

4. Add these data lines: 

11300 DATA 0,0,0,28,28,8,28,58,89, 

24,60,36,36,102,0,0,0 

11310 DATA 0,0,0,28,28,8,28,58,89, 

24,40,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89, 
24,56,72,132,130,0,0,0 
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5. Change line 200 so it reads like this: 

GOSUB PEEK(JOYSTICK): 
GOSUB MOVELEGS:GOTO 200 

6. Insert at line 10050: 

MOVELEGS=30: 

SP=1: 

PR=8 

7. Add a subroutine at line 30 as follows: 

30 POKE HPOSPO, X0: 
PLAYER0$(Y0)=LEGS1$: 
PLAYER0$(Y0)=LEGS2$: 

31 PLAYER0$(Y0)=LEGS3$: 
RETURN 

8. Change line 13040 so it reads: 

PLAYER0$(Y0)=LEGS1$ 


Notice that we are now moving each of the three images, in turn, into 
the PM memoiy area. 

■ Before you run the revised program, write down a prediction as to how it 
will turn out. Then try it. What's the result? 


ANSWER 

(I trust you have tried the experiment by now. If you haven't you might 
want to do that now. You'll learn more that way, honest.) Well, the player's 
legs are moving all right, but they're moving too fasti We need to slow 
them down. First, delete lines 30 and 31 and I'll show you how. 

One way is to set up a counter. We'll use the variable Z for this. To 
increment the counter we simply put the statement "Z=Z+\" at the beginning of 
line 30. 

Remember that our animation routine is based on a loop. Each time we 
pass through the loop, variable Z will be increased by one. Also, our player will 
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be moved to a new position based on the new horizontal and vertical coordi¬ 
nates. Suppose we want the first image to be displayed during the first three 
times through the animation loop. Then we might use an IF-statement at the 
end of line 30. Line 30 would then look like this: 

Z=Z+1 POKE HPOSPO.XO: 

IF Z<4 THEN PLAYER0$(Y0)=LEGS1$: 

RETURN 

Notice the "RETURN" statement that sends control back to the main loop at 
line 200. 

■ Suppose we want image two to be displayed during loop passes 4 
through 6. Code the two statements needed to make that happen. Use 
line 31. 


ANSWER 

31 IF Z<7 THEN PLAYER0S(Y0)=LEGS2$ 
RETURN 


Following the same pattern, we might want to display image three 
during loops 7 through 9. We don't need an IF-statement this time. If Z is 7 or 
greater, control will simply pass to line 32. At line 32 we simply set PLAYEROS to 
the third image. However, when X=9, we will want to reset Z to 0 so that next 
time image one will be displayed. 

■ See if you can code the statements for line 32. 


ANSWER 


Here's how I did it: 

32 PLAYER0$(Y0)=LEGS3$: 
IF Z=9 THEN Z=0: 
RETURN 


■ We need to add a statement on line 33 before this routine will work. See if 
you can figure out what it is. Here's a hint. What happens if X=7? Control 
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will pass to line 32, and the third image will be moved into PLAYEROS. But 
since Z is not equal to 9. . . what will happen? 


ANSWER 

Since Z is not equal to 9, control will pass to the next statement, whatever 
it may happen to be, and we will never return from the subroutine. This 
will lead to problems! Consequently, line 33 needs to be "RETURN" so that 
control will return to the main loop. 


Try it. Make sure lines 30 through 33 read like this: 

30 Z=Z+1 :POKE HPOSPO,XO: 

IF Z<4 THEN PLAYER0$(Y0)=LEGS1 $: 
RETURN 

31 IF Z<7 THEN PLAYER0$(Y0)=LEGS2$: 
RETURN 

32 PLAYER0$(Y0)=LEGS3$: 

IF X=9 THEN X=0: 

RETURN 

33 RETURN 


■ Try this out. What additional problem is there? 


ANSWER 

The player's legs move even when he is standing stilll Fortunately, this is 

easy to fix. Just change line 15 to read: 

15 POP:PLAYERO$(YO)=LEGS1$:GOTO 200 

Control is passed to line 15 when the joystick is not moved—when the 
player is stationary. So we can use this line to display a single image and then 
jump back to line 200. The POP command serves to cancel the GOSUB that 
passed control to line 15. By using "POP" we make it "legal" to use the "GOTO 
200" statement. Without the POP statement, you would eventually end up 
with an error message as a result of "GOTO 200." That's because BASIC is set 
up to expect a RETURN statement at the end of a subroutine. 
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Try adding line 15. If everything goes well, you will find that the player's 
legs move only when you move the joystick! If you want, you can experiment 
with a different "standing still" image of the player. For example, you might 
code line 15 like this: 

15 POP:PLAYERO$(YO)=LEGS2$:GOTO 200 

With this statement, image 2 will be displayed when you leave the joystick in 
the upright position. The program will now work fine. If yours doesn't, you may 
wish to compare it with the listing at the end of this chapter. 


TRAPPING ERRORS 

I promised you I'd explain how to handle those error messages that pop up 
when you move the player too far off the screen. Here's one simple way: 

1. Change line 1 so it reads like this: 

1 TRAP 3000:GOSUB 2000:GOTO 200 

2. Add line 3000: 

3000 PLAYER0$=BUFFER$:Y0=128: 

X0=80:Z=0:TRAP 3000:GOTO 200 

The TRAP at line 1 says, "Trap any error you find. Don't print an error message. 
Instead, just GOTO line 3000. 

■ What do you think line 3000 says? 


ANSWER 

Erase the player image from the screen. (BUFFERS is set to zeros, so setting 
PLAYER0S equal to BUFFERS is the same as setting PLAYER0 to zeros. That, 
in effect, erases the PLAYERS image.) 


After that, the variables Y0 and X0 are set to some specific values. The 
value of 128 for Y0 hides the player off the bottom of the screen. The value 80 
forXO puts the PLAYERS at the left of the center of the screen. The result is that if 
you move the playertoo far off the screen in any direction, she will be automat¬ 
ically repositioned off the bottom of the screen on the left side. To bring her 
back, just push forward on the joystick and she will scoot up onto the screen. 
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The idea here is that the error condition is caused by a bad value in either 
XO or YO. To fix that, we simply trap the error and reset XO and YO to any desired 
"legal" values. In addition, we reset the leg movement counter (Z) to zero. 

Also, notice that we repeat the TRAP command at line 3000, so that if 
another error occurs, we will again branch to line 3000. (A TRAP statement 
must be reset after an error occurs.) 

Ifyou haven'tyet got your player's legs to move, now's the time. You may 
wish to refer to the following program, which is a complete listing of all the 
lines needed to make your player dance! 

Once you have it working, you may wish to animate your player in other 
ways. For example, you might want to add some additional images to make 
the legs move more smoothly—or you may wish to have the player move her 
arms or other body parts. Have funl 


1 TRAP 3000:60SUB 2000:GOTO 200 

2 SAVE “D:LEGS.SAV":STOP :REM DISK 30 

4 REM ADJUST HORIZONTAL .& OERTICAL CO¬ 

ORDINATES 

5 XO=XO+SP:YO=YO+SP:RETURN 

6 yo=yo-sp:xo=xo+sp:return 

7 xo=xo+sp:return 

9 xo=xo-sp:yo=yo+sp:return 

10 xo=xo-sp:yo=yo-sp: return 

11 xo=xo-sp:return 

13 yo=yo+sp:return 

14 YO=YO-SP:RETURN 

15 POP : F'LAYERO$ (YO) =LEGS1$: GOTO 200 

29 REM MOVE PL AVER’S LEGS 

30 Z = Z + l:POKE HPOSF'O, XO: IF Z<4 THEN F'L 
AYERO$(YO)=LEGS1$:RETURN 

31 IF Z<7 THEN PLAYERO* (YO) =LEGS2$: RET 
URN 

32 PLAYERO*<Y0)=LEGS3$:IF Z=9 THEN Z=0 
:RETURN 

33 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK (JOYSTICK) : GOSIJB MOVELEG 

s:goto 200 

260 REM 
270 REM 
280 REM 
290 REM 
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600 GRAPHICS 0:TRAP 610:FOR 1=1 TO 128 

:? i;" ";asc(Playero*<i)):next i:stop 

610 END 

1999 REM SETUP ROUTINES F OLLON- 

2000 GOSUB 10000:REM MlSC. INITIALI¬ 
ZATION 

2005 GRAPHICS 5:REM SET GR. NODE 

BEFORE PMG SETUPf 

2010 GOSUB 11000:REM PMG SETUP 

2015 GOSUB 12000:REM DRAM PLAVF1ELI1 

2020 GOSUB 13000:REM PLAYER COLOR AND 

SCREEN POSITION 

2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 PLAYERO*=BUFFER*:Y0=128:X0=80:Z=0 

:trap 3000 :goto 200 

10000 REM MI SC. INITIALIZATION 
10050 JOYSTICK=632:HP0SP0=53248:PRI0R= 
623:M0VELEGS=30:SP=1:PR=8:RETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2*((INT(AD 
R (FI L.LER 1 $) / 1024) +1) * 1024-ADR (FILLER1 * 
)-l> 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO* (128), PLAYER 1 * (128) , PL.AYER2* (1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER* (2) =B(JFFER* 

11045 MISSILES*=BUFFER*:PLAYERO*=BUFFE 
R*:PLAYER1*=BUFFER*:PLAYER2*=BUFFER*:P 
LAYER3*=BUFFER* 

11050 DIM LEGS1*(17),LEGS2*(17),LEGS3* 
(17) 

11060 FOR 1=1 TO 17:READ A:LEGS1*(I,I) 
=CHR*(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(1,1) 
=CHR*(A):NEXT I 

11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 
=CHR*(A):NEXT I 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 
S 
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11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PMG 
11110 POKE PRIOR,PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36,102,0,0,0 

11310 DATA 0,0,6,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72,132,130,0,0,0 

11999 REM DRAN PLAYFI ELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT 0,20:DRAWTO 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248,XO:REM PONE HORIZON¬ 
TAL VALUE INTO HORIZONTONAL POSITION 
REGISTER. 

13040 PLAYERO$(YO)=LEBS1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. 
13050 RETURN 



Adding Sound 


Now that you have your player dancing around the screen, let's add some 
sound effectsl They can help to make an exciting animation sequence even 
better. 

When you finish this chapter you'll be able to create some interesting 
sound effects to go along with the movement of your players. In addition, 
you’ll learn how to maximize the execution speed of these sound routines. 

I’m going to begin with a brief discussion of the SOUND statement. If 
you're already an expert on this, you may wish to skip ahead to "Chords" in this 
chapter. Otherwise, read on. 


THE SOUND STATEMENT 

Most Atari BASIC programs use the SOUND statement. It's a powerful state¬ 
ment because it enables you to control the pitch, distortion, and volume for 
each of four "voices." 

Yes, Atari has four voices. Before we get into the details of the SOUND 
statement, let's consider what is meant by the term "voice." Think of a four- 
voice choir. In such a choir there are four separate groups of singers. Each 
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group (or "voice") usually sings a separate melody (series of notes). Here are 
the names and ranges of the different voices in a four-voice choir: 

Name of Voice Range 

Soprano (Usually sings highest notes) 

Alto (Next to the highest notes) 

Tenor (Next to the lowest notes) 

Bass (Lowest notes) 

Now back to the SOUND statement. In Atari BASIC the names of the four 
voices are 0,1, 2, 3. (Again, notice that we start counting with "0" rather than 
"1.") Here's how you specify the voice, pitch, distortion, and loudness with a 
sound statement: 

SOUND VOICE,PITCH,DISTORTION,VOLUME 

"SOUND" is a key word such as "GOTO." The other items ("VOICE." 
"PITCH," "DISTORTION," and "VOLUME") are called parameters. Let's call 
them "parms" for short. In the above example they are variables. Before 
executing the above statement, you would need to set these variables to 
appropriate values. 

Alternatively, you could use fixed numerical values (constants) or arithme¬ 
tic expressions in place of those variables. For example, you might write: 

SOUND 0,121,10,8 or SOUND 0,5*20+1,10,8 

Both statements would cause voice 0 to play the note called "Middle C" since 
a value of 121="Middle C." (See page 58 in your ARARI BASIC REFERENCE 
MANUAL for numbers corresponding to the various musical pitches.) 

The "10" in the above statement (the third parm) creates a "pure tone''— 
one with no distortion. Instead of "10," you can use other even numbers 
between 0 and 14 for various sound effects. 

The fourth parm tells Atari how loud you want the sound to be. This 
value can be between 1 and 15. The higher the number, the louder the sound. 

Before we go any further, let’s experiment with a few simple SOUND 
statements. Get your Atari up and running. Then type in this next command 
just like it is—without a line number: 

SOUND 0,121,10,8 

■ When you press RETURN the command will immediately execute. What 
note will you hear? 
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ANSWER 

Middle C. (121 is the value for Middle C, remember.) 
Try it. Then enter this command: 

STOP 

■ What happened? 


ANSWER 

Nothing really. The sound will continue. The STOP command has no effect 
on a SOUND command. To turn off the sound, simply enter the END 
command. Try it 


The END command can come in handy when you decide you want 
some peace and quiet for a change. 


Experiment 

Move the cursor back up to the SOUND command you entered earlier. (To 
move the cursor, hold down the CTRL key while pressing the arrow keys.) Try 
changing the distortion parameter (the third one). Enter various even numbers 
from 0 to 14. Ifyou hear an effect you like,you may wish to make a note ofthe 
SOUND parms. In the same way, experiment with the volume parm by enter¬ 
ing various numbers from 1 to 15. 


CHORDS 

A chord is a combination of musical pitches. It's easy to make chords with the 
Atari. You simple turn on more than one voice. Try this example. It will produce 
what musician's call a C-major chord: 

SOUND 0,243,10,8 
SOUND 1,121,10,8 
SOUND 2,96,10,8 
SOUND 3,81,10,8 
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One caution: if the total of all the volume parms exceeds 32, an un¬ 
pleasant "clipped" tone will result. 

■ In the example above, did I observe this caution? What is the total of the 
volume parameters in the example? 


ANSWER 

Yes. The volume parms add up to exactly 32 (8+8+8+8=32). 


POKING SOUND PARMS 

Because of its ease of use, you may choose to use the SOUND command in 
your programs. But ifyou are coding an animation sequence for, say, a game or 
other simulation, then it may be better to poke sound parms directly into 
memory. SOUND statements execute more slowly than direct pokes. 

Here's how you poke sound parms. To set the pitch of voice 0, simply 
poke a number into memory location 53760. To set the distortion and volume, 
first multiply the desired distortion number by 16 and add it to the value for 
volume. Then poke this one number into 53261. 

For example, instead of writing SOUND 0,121,10,8, you would write: 

POKE 53760,121 
POKE 53761,168 

(We poked 168 into 53761 because 16*10+8=168.) 

■ Now you try it. What POKE commands would be needed to replace this 
SOUND command? 

SOUND 0,96,5,5 


ANSWER 

POKE 53760,96 

POKE 53761,85 (since 5*16+5=85) 

(Try these out. Enter them directly without line numbers.) 
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SOUND REGISTERS 

So far I've shown you only two sound control registers: 53760 and 53761. Here 
is a more complete list: 


Location Used to Control 

53760 Pitch of voice 0 

53761 Distortion and volume of voice 0 

53762 Pitch of voice 1 

53763 Distortion and volume of voice 1 

53764 Pitch of voice 2 

53765 Distortion and volume of voice 2 

53766 Pitch of voice 3 

53767 Distortion and volume of voice 3 

53768 Pitch of all voices 
(More on this later) 


■ Look over these locations for a moment. What do the even numbered 
locations all control? The odd ones? 


ANSWER 

The even numbered locations all control pitch. The odd ones control distor¬ 
tion and volume. 


MORE EXPERIMENTS 

Now let's try some more experiments. Type in and try out this little sound demo 
program. Then read on. 

4 GOTO 10 

5 SAVE "D:GLODE-SAV":STOP 
10 GOSUB ”1000 

20 TRAP 20:: ? CHR$ < 125) : ? :? : ? "ENTER 
GLIDING SPEED (1-255) "51INPUT ST 
30 '? :? "ENTER DISTORTION (EVEN NUMBER 
FROM 0-14) INPUT DIST 

35 D0=16*DIST+V0L 
50 FOR P0=1 TO 255 STEP ST 
60 POKE SO., PO 
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70 POKE DVO,DO 
80 NEXT PO 
90 POKE DVO,0 
100 GOTO 20 

999 END 

1000 80=53760:DV0=53761:S1=53762:DV1=5 
3763:S2=53764:DV2=53765:83=53766:DV3=5 
3767:V0L=8 

1100 RETURN 


Notes on the Sound Demo 

Line 60: POKE SO,PO This is where I specify what pitch to make the sound. 
SO is the pitch control register for voice 0. (I initialized SO to 53760 in the 
subroutine at line 1000.) PO will be some value between 1 and 255. That's 
because you are asked to enter such a number at line 20. 

Line 70: POKE DV0,D0 Here I turn on the distortion and volume of voice 0. 
(I initialized DVO to 53762 in line 1000. 53762 is the distortion and volume 
control register for voice 0.) The value contained in DO was calculated on line 
35. 

Line 35 DO=16*DIST+VOL Here I set DO to the value that is derived from the 
desired distortion and volume. As I mentioned earlier, we do this by first 
multiplying the desired distortion by 16 and then adding the desired volume. 
You'll notice that DIST is set at line 30 in response to the prompt "ENTER 
DISTORTION." I initialized VOL to 8 in line 1000.1 could have set it to any value 
from 0 to 15. 


50 FOR P0=1 TO 255 STEP ST This is the beginning of a FOR/NEXT loop. 
Note the part that says "STEP ST." This command tells the computer how much 
to increment PO at each pass through the loop. ST is set at line 30 in response to 
the prompt "ENTER GLIDING SPEED." If ST is set to, say, 5 then PO will be set to 
1 the first time through the loop, but 6 the second time (since 1+5=6). 

■ Suppose we set ST to 20. What will PO equal on the second pass through 
the loop? 
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ANSWER 


21 (1+20) 


So the higher the value of ST, the bigger change in P0 at each pass 
through the loop. When ST is set to, say, 1, there will be a slow, smooth gliding 
pitch, when ST is set to progressively higher values, the sound changes in pitch 
rapidly and has a shorter duration (since it takes fewer times through the loop 
to reach 255). 

Line 90: POKE DV0,0 This simply turns off the volume for voice 0.1 do this 
so that the sound stops when control returns to the initial prompt at line 20.1 
could also have turned off the sound by poking a 0 into DO. 

Experiment 

If you haven't already done so, I suggest you try experimenting with different 
values for distortion (DIST) and gliding speed (ST). 

Also, you might want to modify the program to make it easier to hear the 
various sounds being produced. For example you might put a delay on the 
FOR/NEXT loop. You could do this by adding this line to the program: 

75 FOR PAUSE=1 to 100:NEXT PAUSE 

Another idea would be to print the value of P0 on the screen so you 
could observe the values being poked into SO. 


USING A LOOP 

Notice how I produced a gliding effect by putting the poke statements inside of 
a loop. In the same way you can put these poke statements within your 
animation loop. This way, you get a kind of gliding effect as your player or 
missile moves around the screen. 

Assignment 

Let's try this with the moving legs routine we developed in the last chapter. 
What we will do is create some interesting "traveling sounds" for our player. 
Whenever the player moves we'll play some sounds. When the player stops, 
the sound will stop. 
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Perhaps you have some ideas about how this might be done. If so, you 
might want to experiment on your own before continuing. 

Traveling Sounds 

Take a look at the program you entered in the previous chapter (which I called 
"LEGS.SAV"). One approach to making traveling sounds might be to add a 
"sound statement" to the "MOVELEGS" subroutine, which begins at line 30. 

A simple way to do this would be to use the variable Z to set the pitch of 
the sound. As you will recall we used Z as a counter to control the display of 
various running images of our player. When Z was less than 4, we displayed 
"LEG1S". When Z was in the range of 4 through 6, we displayed "LEG2S," and 
so on. We added 1 to Z at the beginning of the MOVELEGS routine so that 
each time the routine was called, Z was greater than before. When Z reached 9, 
it was reset to 0. 

Well, we can make Z do double work. Here's how we might do it with a 
sound statement: 

SOUND 0,Z,10,8 

■ Based on what I've said so far, at what line might you insert this sound 
statement? What would the revised line look like? 


ANSWER 

You might insert the statement into line 30, like this: 

30 Z=Z+1:SOUND 0,Z,10,8: 

IF Z<4 THEN PLAYER0$(Y0)=LEGS1$:RETURN 


Before you continue reading, you might want to revise the "LEGS" 
program by changing line 30 as we've just discussed. 


USING POKES 

Suppose you were to use Poke statements to create the sound. First, you might 
initialize these variables: 

S0=53760 

DV0=53761 




Adding Variety / 85 


■ What would SO stand for? DVO? 


ANSWER 

SO would stand for the pitch control register for voice 0. DVO would stand 
for the distortion/volume control register for voice 0. 


■ What would line 30 look like ifyou used Poke statements to create sound? 


ANSWER 

30 Z=Z+1 :POKE S0,Z:POKE DVO, 168: 

IF Z<4 THEN PLAYER0$(Y0)=LEGS1 $: 
RETURN 


(Recall that to find the proper value for a distortion of 10 and a volume of 
8, we multiply 16 times the distortion. This gives us 160. We then add the 
volume (8) to 160 to arrive at the DVO value of 168.) 


ADDING VARIETY 

To give more variety to the sound, you might consider multiplying Z by some 
number. For example: 

POKE SO,Z*TONE:POKE DVO 

With this code, different sounds will be produced depending on the value of 
TONE. For example if TONE=20 then the first time through the loop Z*TONE 
will equal 20; the second, 40; the third 60; and so on. The bigger the value in 
TONE the bigger the jump in pitch that will occur on each pass through the 
MOVELEGS routine. 

At the end of this chapter is a program that will let you experiment with 
different "traveling sounds" for your player. It is similar to the LEGS program 
from the previous chapter. I have circled lines that need to be added or 
changed. 

As you will probably notice, the addition of sound to the program slows 
down the player somewhat. That's one of the trade-offs. The more features you 
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add—like sound, missile firing, collision detection, and so on, the bigger your 
loop becomes and the slower the animation. That's why I've stressed tech¬ 
niques that will help you maximize execution speed—such as poking values 
into sound registers and placing frequently executed code early in the program. 
Of course, machine language is probably the best—although the hardest- 
way to obtain fast player/missile action.* 

Well, speaking of missiles, in our next chapter let's take a look at what 
they are and how to use them. 

1 GOSUB 2000:GOTO 200 

2 SAVE "D:SOUNDRUN.SAV":STOP :rem DISK 
30 

4 REM ADJUST HORIZONTAL St VERTICAL 
COORDINATES 

5 XO-XO+SP:yo-yo+sp:RETURN 

6 yo=yo-sp:xo=xo+sp:return 

7 XO=XO+SP:RETURN 

9 XO-XO-SP:YO-YO+SP:RETURN 

10 xo=xo-sp:yo=yo-sp:return 

11 xo=xo-sp:return 

13 YO=YO+SP:RETURN 

14 YO-YO-SP:RETURN _ 

15 pdp :playero*<yo>=legsi$:(poke dvoTo) 

: GOTO 200 ^ J 

29 REM MO VE PLAYERS LEGS _ 

30 z=z+i :(pok"e so, z*tone: poke dvo7do)po 

KE HPOSPoTxb:IF Z<4 THEN PLAYEROt(YO)= 

LEGS1$:RETURN 

31 IF Z<7 THEN PLAYERO*<YO)=LEGS2$:RET 
URN 

32 PLAYER0*<Y0)=LEGS3$: IF Z=9 THEN 1-0 
:RETURN 

33 RETURN 

_199 REM _ MAIN LOOP _ 

~200 IF PEEK(BUTTONO) =0 THEN GOSUB SETS 
OUND 

204 GOSUB PEEK(JOYSTICK):GOSUB MOVELEG 

S:GQTO 200/ ’ -- 

260 REM 
270 REM 
280 REM 


*When you're ready to dirty your hands with machine language, look for my new book on Player 
Missile Graphics in Assembly Language. 
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290 REM 

600 GRAPHICS 0:TRAP 610:FOR 1=1 TQ 128 

:? i;" ";asc(Playero*(i)):next i:stop 


610 END 


1000 POKE DVOpO:? :? "ENTER distortion 
NUMBER (0-14) "s:INPUT DIST:? "ENTER 
TONE NUMBER (1-28) INPUT TONE 
1010 ? "ENTER VOLUME NUMBER (0-15) 

input vol:do=dist*16+vol:rem do mill 

BE POKED INTO DISTORT I ON/OOL. REGISTER 

1015 ? CHR* (125) : POKE 752,0.*? "Press t 
he fire button to change sound." 

V 1020 RETURN ___ 

1999 REM SETUP ROUTINES POLL ON'. 

2000 GOSUB 10000:REM MISC. INITIALIZA¬ 
TION 

2005 GRAPHICS 5:REM SET GR. MODE 
BEFORE PMG SETUP/ 

2010 GOSUB 11000:REM PMG SETUP 
2015 GOSUB 12000:REM DRAM PLAT FIELD 
2020 GOSUB 13000:REM PLATER COLOR AND 
SCREEN POSITION 


( 2025 GOSUB 14000:REM DISPLAT MESS 


2130 RETURN 


SAGE ^ 


2999 REM ERROR CORRECTION ROUTINE 

3000 PLAYERO*=BUFFER*:Y0=128:X0=80:Z=0 
.'TRAP 3000: GOTO 200 

10000 REM MISC. INITIALIZATION 


( ”l 0050 J OYSTI CK=632: HP0SP0=53248: PR 10R= 
623:M0VELEGS=30:SP=1:PR=8:BUTT0N0=644 
SETSQUND=1OOP:S0=53760 4r _ 



10060 BUTTQN0=644:SETSOUND=1000:80=537 
60:DV0=53761:RETURN _ 


10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1),FILLER2*((INT(AD 
R (FI L.LER 1 *) / 1024) +1) * 1024-ADR (FILLER1 * 
)-l> 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO*(128),PLAYER1$(128),PLAYER2*(1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)=BUFFER* 
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11045 missiles$=buffer$:playero$=buffe 
R*:PLAYER 1$=BUFFER$:PLAYER2$=BUFFER*:P 
LAYER3$=BUFFER$ 

11050 DIM LEGS1 $(17),LEGS2$(17),LEGS3$ 
(17) 

11060 FOR 1=1 TO 17:READ A:LEGS1$(1,1) 
=CHR$(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(I,I> 
=CHR$(A):NEXT I 

11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 
=CHR$(A):NEXT I 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 

S 

11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PMG 
11110 POKE PRIOR,PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36,102,0,0,0 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72,132,130,0,0,0 

11999 REM DRA W PLAY FI ELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT O,20:DRAWTO 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=52 
13010 Y0=12 
13020 POKE 704,88 

13030 POKE 53248,XO:REM POKE 
HORIZONTAL VALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYERO*(YO)=LEGS1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. 

13050 RETURN _ 

14000 ? "To create sound, push fire buT] 




Missiles 


As I mentioned earlier, Atari Player-Missile Graphics was originally designed to 
simplify the creation of arcade-siyle games. These games often include little 
creatures who fire missiles (or bullets) at each other. In this chapter you'll learn 
to create and animate these missiles. Keep in mind that missiles can also serve 
other purposes: they can highlight text in graphics mode 0, for example. 


DEFINING THE MISSILE IMAGE 

There are four missiles available in PMG. All four missiles are stored in a single 
byte in "missile memory." 

■ How many bits wide is a single missile? (Keep in mind that a byte is made 
up of eight bits.) 


ANSWER 

Each missile is two bits wide (in contrast to players, which are eight bits 
wide). 


89 
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Let's look at a map of a single byte of the missile memory area: 

(1283 (645 (323 (163 (83 (43 (23 (13 


0 

0 

0 

0 

0 

0 

ffi 

0 


Since this byte has nothing but zeros in it, no missiles would appear on 
the screen. Now if we wanted to make missile I appear on the screen, we 
might put this binaiy data into a byte of missile memory: 


(1283 (643 (323 (163 (83 (43 (23 (13 


OO 0811 QO 


■ What would be the decimal number needed to turn on missile 1? (Re¬ 
member how we calculated those decimal numbers for players? We do 
the same thing with missiles. The bit on the far right is worth I; the next bit 
to the left is worth 2; the next bit to the left, 4; and so on. Each successive 
bit to the left is worth twice as much as the previous bit.) 


ANSWER 

We need a decimal 12 to create the necessaiy binaiy data in missile mem¬ 
ory since a binaiy 00001100 = a decimal 12. 


■ If we wanted a thinner missile 1, what binaiy data might we use? 


ANSWER 

We could use either 00000100 or 00001000. 
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So if we wanted a thin missile 1, we might use a decimal 4 or 8 to put the 
proper binary data into missile memory. 

■ Ok, try this one. What binary number would you use to turn on missile 0 
so that it has full width? What would the corresponding decimal number 
be? 

Binaiy Number: 

Decimal Number: 


ANSWER 

The binaiy number would be 00000011; the decimal number, 3. 

■ Suppose you wanted to turn on both bits of missiles 0 and 1. What binary 
number would you need? Decimal number? 

Binaiy Number: 

Decimal Number: 


ANSWER 

You'd need a binaiy 00001111 ora decimal 15. 


Ok, so let's say we want to turn on both bits of missile 0. We know that 
we need to put a 3 into missile memory to do this since a binary 00000011 = 3. 
But what specifically do we do to code this? 


Image String 

It's fairly simple. We just create an "image string" similar to the strings we 
defined earlier. Fora missile, a single byte string may be enough. Remember, 
the more bytes in your image string, the taller the player or missile will be. 

Once we have the data in the image string we can easily zap it into the 
missile memory area at machine language speed. This only works, of course, 
because we have carefully defined our PMG area with strings. 
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■ Let's call our missile image string MIMAGES. We need to do two things to 
set up MIMAGES: dimension it and then plug in a decimal 3. See ifyou can 
write the code to do it. (It will go into your new program as line 11070.) 


ANSWER 

Here's one way: 

11070 DIM MIMAGE0$(1):MIMAGE0$=CHR$(3) 

(I suggest you enter SOUNDRUN.SAV—the program from the previous 
chapter—and add the new statements as you read along.) 


HORIZONTAL POSITION REGISTER 

Let's initialize another variable for the horizontal position register for missile 0. 
We'll call it HPOSMO. So at line 10060, we add this statement: 

HPOMSO=53252 

(Note that HPOSMO ends with a zero, not the letter "O.") 

Another minor change to make in SOUNDRUN is the automatic save 
routine at line 2. Change it to: 

2 SAVE “D:MISSILE.SAV”:STOP 

That way you won't wipe out the previous program when you save this one. 

REVISING THE MAIN LOOP 

Since we will be using the joystick button to fire missiles, we need to delete line 
200 from the SOUNDRUN program. After deleting line 200, renumber line 204 
so that it now becomes 200. Line 200 will now read: 

200 GOSUB PEEK (JOYSTICK):GOSUB MOVELEGS: 
GOTO 200 

Also, let's delete these pokes from line 30: 

POKE S0,X*TONE 
POKE DV0,D0 

since we won't be including player traveling sounds this time. 
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■ In a moment we are going to add a routine to move our missile. We want 
line 200 to fall through to this new routine. So what change do we need 
to make to our new line 200 shown above? 


ANSWER 

We need to delete GOTO 200; otherwise control will not fall through to 
our new routine. 


BUILDING A MISSILE MOVE ROUTINE 

As you know, we have set up our player move routine so that our player can 
move in any one of the eight joystick directions (up, down, left, right, plus the 
four diagonal directions). Wouldn't it be nice if our player could also fire a 
missile in anyone of those directions? 

To make this work, let's make a rule that a player must be moving when 
she fires a missile. Furthermore, the missile will go in the same direction as the 
player. Now, how do we write the code to accomplish this? 

First, we need to identify when the fire button is pressed while the stick is 
also being deflected from its upright position. If that happens, we will set a 
variable called MOVEO to the stick value. For example, if the stick is moved to 
the left while the fire button is pressed, we will set MOVEO to 11. (The stick 
value for left is 11.) Also we will increment an "indicator"—a variable that we 
will call FIRE0. This variable will help the routine remember that the joystick 
was pressed. Also, it will serve as a counter. It will count the number of passes 
that have been made through the missile move routine. We need this because 
we need to do different things on the first pass through the loop than on 
successive passes. 

■ Got all that? See if you can write the code for it. 


ANSWER 

Here's how I did it: 

IF PEEK(BUTTON)=0 AND 
PEEK(JOYSTICK)<>15 
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THEN 

MOVEO=PEEK( JOYSTICK): 
FIRE0=FIRE0+1 


Of course. Atari won't pay any attention to this fancy indentation. But it 
does make it easier to read. It's also easier for me to type on my ATARI TEXT 
WIZARD. This will be line 301. (Yes, there is a line 300. But it will come later. For 
nowjust put a REM at line 300.) 

Next, we need to be able to jump out of this loop if the fire button was 
not pressed. We can't just peek at BUTTONO to decide whether to leave the 
missile routine because BUTTONO will return to zero as soon as the button is 
released.* If we relied on BUTTONO, then on the second pass through the loop 
our missile would stop. 

So we look at FIRE0. If it equals 0 then we know we need to return to line 
200. The code would then be: 

305 IF FIRE0=0 THEN GOTO 200 

Positioning the Missile 

The first time through the missile move routine, we need to plop the missile 
down on the screen "underneath" our player so that when the missile is 
moved on subsequent passes through the loop, the missile will appear to be 
coming from him. 

■ How does the routine detect the first pass? 


ANSWER 

With a statement such as IF FIRE0=1 THEN.... 


On first pass through the missile move routine we will also want to: 

• Set DIR0 to a number representing the direction we want the missile to 
move. (Again that will be the familiarjoystick value such as 7 for right, 
14 for up, and so on.) 

• Add 1 to FIRE0 so that on the next pass through the loop FIRE0 will be 
greater than 1. 


‘Technical note: there is a way to "latch" the fire button so that location 644 is not reset as soon as 
the button is released. I find it easier to use this method, however. 
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■ Consider for a moment what the code might look like for doing that: 



ANSWER 

Here's one way: 


315 IF FIRE0=1 THEN 


MX0=X0+3: 


MY0=Y0+7: 


DIRO=MOVEO: 


FIRE0=FIRE0+1 



Note that with this code, DIRO will be set to the stick deflection value only 
on the first pass through the loop. Also notice that I set MYO to YO+7. That's 
because I wanted to move the missile down a bit from the player image. 
Remember that the player image has zeros at the top so she erases herself as 
she moves down the screen.* I set MXO to XO+3 because a value of XO would 
put the missile at the far left edge of the player image—I want tht missile to be 
hidden "underneath" the player. 

Putting the Missile on the Screen 

■ Now we're ready to put the missile on the screen! We simply erase the 
data in MISSILESS, POKE HPOSMO with MXO, and set MISSILESS(MYO) 
equal to our missile image string. Can you write the code? 


ANSWER 


335 MISSILES$=BUFFER$: 

POKE HPOSMO.MXO: 
MISSILES$(MYO)=MIMAGEO$ 


Also, we'll need to make these changes: 
Add this to line 10060: 

HPOSMO=53252 


*By now you have probably noticed that I sometimes refer to our player as male and sometimes as 
female. Working with a feminist writer taught me to do this as a way to avoid sexist writing. I hope 
it doesn't jar you too much. Of course, you might still complain that the player doesn't look at all 
female—oh well. 
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Add line 11070: 

11070 DIM MIMAGE0$(1 ):MIMAGE0$=CHR$(3) 

Change lines 13000 and 13010 to: 

13000 X0=120 

13010 YO+43 

Change line 2 to: 

SAVE “D:M1SSILE.SAV”:ST0P 

Change line 14000 to: 

14000 ? “To fire missile, move joystick and push fire 

button.”:RETURN 

Change line 15 so it reads: 

15 POP:PLAYER0$(Y0)=LEGS1$: 

GOTO 300 

Delete lines 1000 through 1020. 

Now (finally) we're about ready to take a preliminaiy test run of our 
missile routine. (Assuming you've typed in all of the preceding lines along the 
way.) But first, in line 315 change MX0=X0+3 to: 

MX0=X0-10 

Why? Because I want you to be able to see the missile so you can verify that 
your routine is working at this point. Otherwise, the missile will be positioned 
directionally on top of the player and you won't be able to see it. (Remember, 
the missile is normally the same color as the player it belongs to.) 

Also, put a stop at line 340just to temporarily freeze the action so you can 
see exactly where the missile appears when you press the fire button. 

I've covered a lot, I know. So for your convenience, here is a listing of the 
new program with the changes circled, 

1 GQSUB 2000:GOTO 200 _ 

C 2 SAVE "D: MISSILE.SAV":STOP :REM DISK) 

30 - _—-—- 

4 REM ADJUST HORIZONTAL & VERTICAL 
COORDINATES 

5 xo=xo+sp:yo=yo+sp:RETURN 
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6 yo=yo-sp:xo=xo+sp:return 

7 XO=XO+SP:RETURN 

9 xo=xo-sp:yo*yo+sp:return 

10 xo=xo-sp:yo=yo-sp:return 

11 XO=XO-SP:RETURN 

13 YO=YO+SP:RETURN 

14 YO=YO-SP:RETURN _ 

e_15 POP : PLAYERO* (Y0)=LEGS1*: GOTO 300) 

29 REN MOVE PLAYER'S LEGS ~ 

/ 30 Z=Z+1:P0KE HPOSPO,XO: IF Z<4 THEN PL^ 
\ AYERO*(YO)=LEGS1*:RETURN _ J 

31 IF Z<7 THEN PLAYERO*(YO)=LEGS2*:RET 
URN 

32 PLAYERO*<Y0)=LEGS3*:IF Z=9 THEN Z=0 
:RETURN 

33 RETURN 

199 REM MAIN LOOP 

200 GOSUB PEEK(JOYSTICK):GOSUB MOVELEG 

260“GOTO DO" 

270 REM 
280 REM 

290 REM __ 

f 300 REM ' "' v \ 

301 IF PEEK<BUTT0N0)=0 AND PEEK(JGYSTI 
CK)< >15 THEN MOVEO=PEEK(JOYSTICK):FIRE 
0=FIRE0+1 

305 IF FIRE0=0 THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0-10:MY0=Y0+7 

:DIRO=MOVEO:FIREO=FIREO+1 

335 MISSILES*=BUFFER*:POKE HPOSMO,MXO: 

\ MISSILES*(MYO)=MIMAGEO* 

> 340 STOP ___ 

600 GRAPHICS 0:TRAP 610:FDR 1=1 TO 128 
:? 15" "5 ASC(PLAYERO*(I)):NEXT I:STOP 

610 ENQ^-"" 1 °00 through /OSLO 

1999 REM SETUP ROUTINES POL LON: 

2000 GOSUB ioooo:rem misc. initiali¬ 
zation 

2005 GRAPHICS 5:REM SET GR. MODE 
BEFORE PNG SETUP' 

2010 GOSUB 11000:REM PNG SETUP 
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2015 GOSUB 12000: REM DRAM PL AY FIELD 
2020 GOSUB 13000:REM PLAYER COLOR AND 
SCREEN POSITION 

2025 GOSUB 14000:REM DISPLAY MESSAGE 
2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 PLAYERO*=BUFFER*:Y0=128:XO=BO:Z=0 
:trap 3000:goto 200 

10000 REM MISC. INITIALIZATION 
10050 JOYSTICK=632: HP0SP0=53248: F'RIOR= 
623:M0VELEGS=30:SP=1:PR=8:BUTT0N0=644: 
SETS0UND=1000:S0=53760 

10060 BUTT0N0=644:SETSOUN D=1 OOP: S0=537 
60: DV0=53761: HF'0SM0=53252ilHP0SM0=53252 ) 
: RETURN ^ 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1$(1), FILLER2* <(INT(AD 
R(FILLER1*)/1024)+1)*1024-ADR(FILLER1* 
)-l) 

11010 DIM BUFFER*(384),MISSILES*(128), 
F'LAYERO* <128), PLAYER 1* (128) , PLAYER2* (1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)=BUFFER* 

11045 MISSI LES*=BUFFER*: F'LAYERO*=BUFFE 
R*: PLAYER 1 *=BUFFER*: F'LAYER2*=BUFFER*: P 
LAYER3*=BUFFER* 

11050 DIM LEGS1*(17),LEGS2*(17),LEGS3* 
(17) 

11060 FOR 1=1 TO 17:READ A:LEGS1*(1,1) 
=CHR*(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(1,1) 
=CHR*(A):NEXT I 

11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 

=CHR*(A):NEXT I _ 

1070 DIM MIMAGEO*(1):MIMAGEO*=CHR*(3?) 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF F'M MEMORY I 
S 

11085 POKE 559,46:REM DOUBLE LINE RES. 
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11090 POKE 53277,3:REM TURN ON PMG 
11110 POKE PRIOR,PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36,102,0,0,0 

11310 DATA 0,0,6,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 


6,72,132,130,0,0,0 

11999 REM DRAM PLAYFIELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT 0,20:DRAWT0 40,20 

12020 COLOR 3:DRAWT0 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 




-43 0 


a 


000 xo= 

13010 Y0= 

13020 POKE 704,88 
13030 POKE 53248,XO:REM POKE HORI¬ 
ZONTAL VALUE INTO HORIZONTONAL POSIT 10 
N REBISTER. 

13040 PLAYERO* (YO) =L.EQS 1 *: REM PU T 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 
13050 RETURN 


14000 ? "To fire missile , moue joyst 
and push fire button RETURN 




When your new program is working properly, the missile will appear to 
the left of the player. That's because we set the horizontal coordinate (MXO) to 
ten less than the player coordinate. Now that we've got the missile on the 
screen, let's see about moving it. But first, go back and change line 315 so it says 
MX0=X0+3. 

Moving the Missile 

Now let's get on with animating that missile. For now, delete the TRAP state¬ 
ment from line 1. Now, remember lines 5 through 15? Let's review. We used 
them to adjust the coordinates for the player's position. If the stick reading is 7 
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(right), then we GOSUB 7. Line 7 is a "minisubroutine" that increments XO and 
immediately returns. We can use that same approach to move our missiles. To 
do that; we will write a similar routine that starts at an offset of 60 from the first 
one. That is, instead of beginning at line 5, our new missile subroutine will start 
at line 65 (5+60). Instead of adjusting XO and Y0, we will adjust MXO and MYO, 
the missile coordinates. Here is the complete missile coordinate adjustment 
routine: 

65 MXO=MXO+MSO:MYO=MYO+MSO:RETURN 

66 MYO=MYO—MSO:MXO=MXO+MSO:RETURN 

67 MXO=MXO+MSO:RETURN 

69 MXO=MXO-MSO:MYO=MYO+MSO: RETURN 

70 MXO=MXO—MSO:MYO=MYO-MSO:RETURN 

71 MXO=MXO-MSO:RETURN 

73 MYO=MYO+MSO:RETURN 

74 MYO=MYO-MSO:RETURN 

Notice that we are now using MSO to increment or decrement our missile 
coordinates. (MS0=Speed of Missile 0.) 

In addition to the above lines, we will need these lines in our missile 
move routine: 

320 IF FIRE0>1 THEN GOSUB DIR0+60 

449 GOTO 200 


■ According to line 320, where will control pass if the joystick is pushed 
forward? (Hint: the number 14 is returned when you push the stick 
forward.) 


ANSWER 

Control will pass to line 74 (14+60). 

■ What happens at line 74? 


ANSWER 

We decrement MYO, and the effect is that our missile will move up the 
screen. (The smaller MYO, the higher will be the position of the missile on 
the screen.) _ 
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Let's try it. In summary: 

1. Add lines 65 through 75 above. 

2. Add line 320. 

3. In line 10060 initialize MSO to 6 (MS0=6). 

4. Delete line 340. 

5. Add line 499. 

6. Delete the TRAP statement from line 1. 

Then, save and then run the program. If all went well, your player can 
now fire the missile in any one of six directons! 


ERROR ROUTINE 

Having played around a bit firing missiles, you are probably tired of seeing that 
error message pop up. You know, the one that comes up every time you fire a 
missile off the screen. That's fairly easy to fix. Let's write an error correction 
routine for it. 

Once again, let's begin our program with a TRAP statement at line 1: 

1 TRAP 3000:GOSUB 2000:GOTO 200 

Whenever an error occurs, program control will branch to line 3000. I've 
used a high line number so that the trap routine is out of the way of our main 
loop. Now when an error occurs, control will pass to an error correction routine 
at line 3000. The error correction routine will check for various error conditions 
and then correct them. I know, we did this in a previous chapter, but this time 
the correction routine will be a bit more detailed. 

First, let's handle the situation where the player moves off the screen too 
far to the right. Horizontal coordinate 210 isjust off the screen to the right. So if 
the X0 coordinate is greater than 210 let's reset X0 to 210. The statement IF 
X0>210 THEN X0=210 will do that nicely. 

In the same way we can reset the other X0 and Y0 values if they move 
too far off the screen. Like this: 

3000 IF X0>210 THEN X0=210 

3010 IF X0<39 THEN X0=39 

3020 IF Y0<1 THEN Y0=1 

3030 IF Y0>128 THEN Y0=128 
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In addition, we need to reset the leg movement counter Z. We can do 
that with the statement Z=0. Let's add it at line 3035: 

3035 Z=0 

That takes care of our player. Now she can hide off the screen—even move 
around off-screen and then come back. 

Let's fix the missile, too. Here's a simple way to do it for now: reset the XO 
and Y0 coordinates whenever an error occurs. Reset them to what? Well, let's 
simply reset them to the player's coordinates, like this: 

3040 MX0=X0:MY0=Y0 

Also, we need to turn off the missile sound when an error occurs. We can 
do that simply by setting D1 to zero: 

3050 D1=0 

Next, we need to turn off the missile routine, so it doesn't continue to 
adjust the MX0 and MY0 coordinates. We do that by setting FIRE0 to zero: 

3060 FIRE0=0 

Finally, we need to include another TRAP statement so that if another 
error occurs control will once again return to line 3000. Then we canjump back 
to line 300 in the main routine: 

3080 TRAP3000:GOTO 200 

Add these lines. Then you'll be able to fire missiles from an ambush 
position—while the player is hiding off the screenl 

Our missile move routine is now pretty much finished. But let's add a few 
embellishments. First, let's add sound to the firing of the missile. 

Add line 300 as follows: 

300 POKE SD1 ,P1: 

POKE DV1.D1 

At line 10070 initialize PI, D1, SD1, and DV1 as follows: 

P1=10 (Pitch for sound) 

D1=0 (Distortion/Volume) 

SD1 =53762 (Pitch Register) 

DV1 =53763 (Distortion/Volume Register) 
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Also, remove the RETURN from line 10060 and put RETURN at line 10900. 
Now we can use variable D1 to set the volume of our missile sound. A 
good place to do this is on the first pass through the missile loop. If we set the 
volume to maximum on the first pass and then decrement it on each successive 
pass, we can create an explosive type sound that gradually fades away. We 
can set the volume to maximum by writing Dl=15. 

■ Where would be a good place to insert that statement? 


ANSWER 

At line 315 where we test to see if we are on the first pass through the 
missile routine. So add D1=I5 to the end of line 315. 


Now we still need to decrement DI. Let's do that at line 330. We can 
decrement Dl easily enough with DI =D1 -1. But that's not enough, because that 
way DI will eventually become a minus value and we will get an errror 
message. 

■ How can we avoid that? Write the code. 


ANSWER 

Here's how I did it: 

330 D1=D1-1:IF D1<1 THEN D1=0 


Add line 330. Save the program and run it. You will now hear an explosive 
sound whenever you fire a missile. 


MISSILE SIZE REGISTER 

Now let's play with the missile size register. That's a register that lets us instantly 
increase or decrease the width of a missile. We can set a missile's size to nor¬ 
mal, double, or quadruple width. The missile size register, at location 53260, 
controls the size of all missiles. 
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Here's a chart showing the proper numbers to poke in for various missile 

sizes. 


Missile 

Number 

0 

1 

2 
3 


Normal 

0 

0 

0 

0 


Double 

1 

4 

16 

64 


Quadruple 

3 

12 

48 

192 


Important: if you want to set the size of two or more missiles at once, 
then add the proper values for each missile depending on the desired size. 
Then poke the total into location 53260. 

For example, to set missile 3 to quadruple size and missile 1 to double 
size, you would poke 196 into 53260. (192 gives quad size for missile 3, and 4 
gives double size for missile 1. We get 196 by adding 192 and 4.) 

■ Suppose you wanted to set missile 0 to quad size and missile 1 to double 
size? What number would you poke into 53260? 


ANSWER 


7 (3+4=7) 


■ How would you set missiles 0 and I to double size? 


ANSWER 

POKE 53260,5 


To make our program easier to read, let's set up a variable called SIZEM 
(size of missiles) at line 10070, like so: SIZEM=53260. 

We can create a nice effect by poking a random number into SIZEM. First 
(also at line 10070) let's set up a variable called RANDOM: RANDOM=53770. 
Location 53770 is constantly being updated by Atari's operating system with a 
random number. So a quick way to get a random number is to "peek" into 
location 53770. 
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■ Write a statement to poke a random number into the size register for 
missiles. 


ANSWER 

Here's one easy way: 

POKE SIZEM.PEEK(RANDOM) 

Try it. Be sure to initialize SIZEM and RANDOM at line 10070. Then add 
POKE SIZEM,PEEK(RANDOM) to line 300. 

You'll now see the missile randomly expand to various widths as it sails 
across the screen. Notice the different effect produced by firing the missile 
vertically versus firing it horizontally. 


COMPLETE LISTING 

Here is a complete listing of the missile program that we have developed in 
this chapter. Again, I have circled the lines that are to be changed or added. Be 
sure to save it to disk or tape. You'll need it. Remember, each chapter will build 
on the previous program in some way. 

In the next chapter, you learn how to create single-line resolution PMGI 


1 TRAP 3000:G0SUB 2000:GOTO 200 

2 SAVE "D: MISSILE.SAV":STOP : REM DISK 
30 

4 REM ADJUST HORIZONTAL & VERTICAL 
COORDINATES 

5 xo=xo+sp:yo=yo+sp:return 

6 yo=yo-sp:xo=xo+sp:return 

7 xo=xo+sp:return 

9 xo=xo-sp:yo=yo+sp:return 

10 xo=xo-sp:yo=yo-sp:return 

11 X0=X0-SP:RETURN 

13 Y0=Y0+SP:RETURN 

14 YO=YO-SP:RETURN 

15 POP :PLAYERO*(YO)=LEGS1$:GOTO 300 

29 REM MOVE PL AVER’S LEGS 

30 z=z+i:poke hpospo, xo: if z<4 then pl. 
AYERO$(YO)=LEGS1 *:RETURN 
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31 IF Z<7 THEN PLAYERO*(YO)=LEGS2*:RET 
URN 

32 PLAYEROi* (YO) =LEGS3$: IF Z=9 THEN Z=0 
:RETURN 

33 RETURN ___ _ - 

f 65 mxo=mxo+mso:myo=myo+mso:return^ 

66 MY0=MY0-MS0:MXO=MXO+MSO:RETURN 

67 MXO=MXO+MSO:RETURN 

69 MXO=MXO-MSO:MYO=MYO+MSO:RETURN 

70 MXO=MXO-MSO:MYO=MYO-MSO:RETURN 

71 MXO=MXO-MSO:RETURN 

73 MY0=MY0+MS0:RETURN 

74 MY0=MY0-MS0:RETURN ____ 

199 13EFi MAIN LOOP 

200 GOSUB PEEK(JOYSTICK):GOSUB MOVELEG 
S 

260 REM 
270 REM 
280 REM 

290 REM _ _ 

300 POKE SD1,P1:P0KE DV1,D1ZP0KE SIZEM 

,PEEK(RANDOM) _ 

301 IF PEEK(BUTTONO)=0 AND PEEK(JOYSTf 
CK)< >15 THEN M0VE0=PEEK(JOYSTICK):FIRE 
0=FIRE0+1 


305 IF FIREO-O THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0+3:MY0=Y0+7: 


DI RO=MQVEO; FI R‘EO=F IREO+1: D1 = 15 _ 

f 320~ IF FIRE0>1 THEN GOSUB DIR0+60 ^ 

l 330 Dl=Dl-l:IF D1 < 1 THEN D1=0 _ J 

335 MISSILES*=BUFFER*:POKE HPOSMO.MXO: 

dOK ,=MI " flGE0 ’ 34-0 

600 GRAPHICS 0:TRAP 610:F0R 1=1 TO 12B 
:? i;" ";asc(Playero*(i)):next izstop 

610 END 

1999 REM SETUP ROUTINES FOLLONi 

2000 GOSUB 10000:REM MISC. INITIALI¬ 


ZATION 


2005 GRAPHICS 5:REM SET GR. MODE 
BEFORE PMG SETUP.' 

2010 GOSUB 11000:REM PMG SETUP 
2015 GOSUB 12000:REM DRAM PLAV FI ELD 
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2020 GOSUB 13000:REM PLOVER COLOR ONV 
SCREEN POSITION 

2025 GOSUB 14000: REM TJISPLOY MESSOGE 
2130 RETURN 

2999 REM ERROR CORRECTION ROU TINE 


5000 IF X0>210 THEN X0=210 
3010 IF X0<39 THEN X0=39 
3020 IF Y0<1 THEN Y0=1 
3030 IF Y0>128 THEN Y0=12B 
3035 1=0 

3040 MXO=XO:MYO=YO 
3050 D1=0 
3060 FIRE0=0 

3080 TRAP 3000:GOTO 300- 




10000 REM MISC. I NIT IOLIZOTION 
10050 JOYSTI CK=632: HF'0SP0=53248: PR 10R= 
623: M0VELEGS=30: SF'=1: PR-8: BUTT0N0=644: 
SETSOUND=1000:30=53760 

10060 BUTT0N0=644:SETSOUND=1000:S0=537 
6 0:DV0= 557Al: HF'0SM0=53252: HF'0SM0=53252 

RCT-UR^ - 

Al 0070 P1 = 10:D1=0:SD1=53762:DV1=53763 

[ IZEM=53260:RAND0M=53770 _ 

10900 RETURN 

10999 REM PMG SETUP ROUTINE 

11000 DIM FILLER1*(1),FILLER2*((INT(AD 
R (FILLER1$)/1024)+1)* 1024-ADR(FILLER1 * 
)-l> 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO*(128),PLAYER1*(128),PLAYER2*(1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)=BUFFER* 

11045 MISSILES*=BUFFER*:PLAYERO*=BUFFE 
R*:PLAYER1*=BUFFER*:PLAYER2*=BUFFER*: P 
LAYER3*=BUFFER* 

11050 DIM LEGS1* <17) ,LEGS2*(17),LEGS3* 
(17) 

11060 FOR 1=1 TO 17:READ A:LEGS1*(1,1) 
=CHR*(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(1,1) 
=CHR*(A):NEXT I 
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11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 
=CHR$(A):NEXT I 

11070 DIM MIMAGE0*(1):MIMAGE0$=CHR*(3) 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 
S 

11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PMG 
11110 POKE PRIOR,PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36,102,0,0,0 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72,132,130,0,0,0 

11999 REM DRAM PL AY FI ELD 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT O,20:DRAWTO 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2: DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET PLAYER COLOR AND 
POSITION 

13000 X0=120 
13010 Y0=43 
13020 POKE 704,88 

13030 POKE 53248,XO:REM POKE HORI¬ 
ZONTAL OALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYER0*(Y0)=LEGS1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. VO 
DETERMINES VERTICAL POSITION 
13050 RETURN 

14000 ? 11 To fire missilemove Joystic 
k and pash fire button .":RETURN 



Single-line Resolution 


So far we have been dealing strictly with double-line resolution. Since double¬ 
line resolution is easier to handle and takes less memory. I'll continue to use it 
for most of the examples in this book. But our little player is so cute in single- 
line resolution! I just couldn't resist introducing him to you. 

Be sure to save copies of the previous double-line resolution programs, 
since future programs will be based on them—not on the program in this chap¬ 
ter. In fact, I suggest you just read over this chapter without typing in any of the 
examples. Then afteryou've mastered double-line resolution, come back and try 
out the program in this chapter. (Whatever. You'll do it your way, anyway.) 

At the end of this chapter is a complete listing of a program that does 
essentially the same thing as the program in the previous chapter—the only 
difference is that it is in single-line resolution. The program is called SLRES.SAV— 
short for "single-line resolution." Here is a summary of the changes you'll need 
to make to MISSILE.SAV to produce SLRES.SAV: 


LINE 11000 

This is the "filler" line that makes sure that PM memory starts on a 2K boundary. 
The only change is that while the number 1024 appeared in the previous 
program, 2048 appears in this program (I024=1K: 2048=2K|. 
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LINE 11010 

In the previous program I had a string called BUFFERS dimensioned to 384 
bytes. Well, in single-line resolution, this string needs to be twice as many 
bytes: 384*2 or 768. 

Instead of dimensioning BUFFERS to 768 bytes, I broke it down into three 
strings of 256 bytes each: ERASES, FILLER3S, and FILLER4S. (Notice that it works 
out to be the same thing since 3*256=768.) Also, notice that each of the other 
strings are now 256 bytes long instead of 128—the way they were in double¬ 
line resolution. And notice that I omitted the dimensioning of PLAYER1S, 
PLAYER2S, and PLAYER3S. 


LINES 11020 THROUGH 11040 

Here I am setting ERASES to binary zeros. Notice the RETURN at the end of line 
1040.1 broke the PMG setup routine into two parts. (For some unknown reason 
BASIC likes it better this way.) 

Lines 11045 through 11095 make up the next part of the PMG setup. I 
made these lines into another subroutine, which is called immediately after the 
subroutine starting at line 11000. (See the "executive" subroutine beginning at 
line 2000, which calls the various setup routines.) 


LINES 11045 AND 11047 

Here I am initializing MISSILESS and PLAYER0S in a slightly different way. This is 
necessary because of an apparent bug in Atari BASIC. It seems that a statement 
such as MISSILES$=ERASE$ won't work if MISSILESS is 256 bytes or more. 

In the previous program, line 335 contained the statement MISSILESS 
=BUFFERS, which served to "erase" data from the missile memory area. (Actual¬ 
ly it fills MISSILESS with zeros.) I had to take this statement out when converting 
the program to single-line resolution. That's because of the apparent bug in 
Atari BASIC that I just mentioned. 

So to accomplish vertical missile movement, I had to find another way to 
erase the missile. I did that by rewriting lines 11070 and 11330. 


LINES 11070 AND 11330 

At line 11070 I dimensioned the missile image string to 13, instead of 1. Why? 
Because I wanted to have the missile erase itself with trailing zeros during 
vertical movement. 
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Notice the zeros in the missile image data at line 11330. These zeros erase 
the missile as it moves vertically. Using this arrangement, I found that I didn't 
need the statement "MISSILES$=ERASE$" at line 335. 


UNE 11085 

This is important. Here I specify single resolution by adding 16 to the 46 that is 
to be poked into location 559, the direct memory access control register. I'll 
explain this more later. (See the "Odds and Ends" chapter if you can't wait.) 


LINES 5 THROUGH 14 

Here I use SY to adjust Y0, where previously I used SP. SY refers to "speed of Y 
(up/down) movement." In single-line resolution, remember, there are twice as 
many vertical locations. So to get approximately the same vertical speed, we 
have to move the player 2 bytes instead ofjust 1. Consequently, SY is initialized 
to 2 in line 10070 and SP is still initialized to 1. Horizontal movement is no 
different in single- versus double-line resolution. 

A similar change could also be made for the missile coordinate adjust¬ 
ment routine at lines 60 through 75. When you get this program running, 
notice how the missiles don't go exactly as you might expect when you fire 
them in a diagonal direction. That's because in single-line resolution there are 
about 224 vertical positions, but only 150 horizontal ones. 


UNE 10070 

In line 10070 I initialized SY to 2 as I just mentioned. 


UNE 315 

To line 315 I added: 

MY0S=MY0 

MY0S is short for MY0SAVE. Here I am saving the vertical coordinate for the 
missile. Notice that I am doing this when the missile's vertical coordinate is first 
set. I use this saved value later in the error correction routine (which begins at 
line 3000) to help me erase the missile from the screen. 
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LINES 3000 THROUGH 3080 

The error correction routine at lines 3000 through 3080 needed quite an over¬ 
haul because of the differences in vertical coordinates in single-line resolution. 
Also the manner in which I erase a missile is different. I now need to reference 
specific bytes in MISSILESS when erasing the missile. I can no longer merely 
code MISSILES$=BUFFER$ to set the missile memory area to zeros. Again, this is 
necessary because of an apparent bug in Atari BASIC. 

That does it. The complete listing for firing missiles in single-line resolu¬ 
tion follows. To make the required changes easy to see, I have circled them. 
Notice that in line 2,1 made a comment to myself that I saved the program on 
disk 30. I suggest you revise this REM statement so it reminds you where you 
saved the program. In the next chapter, we'll put our player in a maze and add 
collision detection! 

1 TRAP 3000:G0SUB 2000:GOTO 200 _ 

( J2 SAVE "D: SLRES. SAV" : STOP : REM DISH JO j 

4 REM fiDJUST HORIZONTAL & VERTICAL 
COORDINATES 

5 xo=xo+sp:yo=yo+sy:return 

6 yo=yo-sy:xo=xo+sp:return 

7 xo=xo+sp:return 

9 xo=xo-sp:yo=yo+sy:return 

10 xo=xo-sp:yo=yo-sy:return 
u xo=xo-sp:return 

13 yo=yo+sy:return 

14 YO=YO-SY:RETURN 

15 POP :PLAYERO$(YO)=LEGSl*:GOTO 300 

29 REM MOVE PL AVER'S LEGS 

30 Z=Z + l:POKE HPOBF‘0, XO: IF Z<4 THEN PL 
AYERO*(YO)=LEGS1*:RETURN 

31 IF Z<7 THEN PLAYERO*(YO)=LEGS2$:RET 
URN 

32 F'LAYERO# (YO) =LEGS3$: IF Z=9 THEN Z=0 
:RETURN 

33 RETURN 

65 MXO=MXO+MSO:MY0=MY0+MS0:RETURN 

66 MYO=MYO~MSO:MXO=MXO+MSO:RETURN 

67 MXO=MXO+MSO:RETURN 

69 MXO=MXO-MSO:MYO=MYO+MSO:RETURN 

70 MXO=MXO-MSO:MYO=MYO-MSO:RETURN 

71 MXO=MXO-MSO:RETURN 
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73 MY0=MY0+MS0:RETURN 

74 MY0=MY0-MS0:RETURN 

199 REM MAIN LOOP 

200 60SUB PEEK(JOYSTICK):GOSUB MOVELEG 


260 REM 
270 REM 
280 REM 
290 REM 

300 POKE SD1,PI:POKE DV1,D1:P0KE SIZEM 
,PEEK(RANDOM) 

301 IF PEEK(BUTTONO)=0 AND PEEK(JOYSTI 
CK)015 THEN MOVEO=PEEK(JOYSTICK):FIRE 
0=FIRE0+1 

305 IF FIRE0=0 THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0+3:M Y0=Y0+7: 

DIR0=M0VEO: FIREO=FIREO+1 : D1 = 15 $MYOS=MY 

3 ) *- 

320 IF FIREO>1 THEN GOSUB DIR0+60 

330 Dl=Dl-l:IF D1<1 THEN D1=0 _ 

I 335 POKE HPOSMO,,MXO:MISSILES*(MYO)=MIM > 

( AGEO$ ______ 

499 GOTO 200 

600 GRAPHICS 0:TRAP 610:FOR 1=1 TO 128 
: ? is" ";ASC(PLAYERO*(I)):NEXT I:STOP 


610 END 

1999 REM SETUP ROUTINES FOLLOMi 

2000 GOSUB 10000:REM MISC. INITIALI¬ 
ZATION 

2005 GRAPHICS 5:REM SET GR. MODE 
BEFORE PMG SETUP.' 

2010 GOSUB 11000:GOSUB 11045:REM PMG 
SE TUP 

2015 GOSUB 12000:REM BRAN PLAYFIELB 
2020 GOSUB 13000:REM PLAYER COLOR AND 
SCREEN POSITION 

2025 GOSUB 14000:REM BISPLAY MESSAGE 
2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 IF X0>210 THEN X0=210:REM CORRECT 
PLAYER COORBINATES 

3010 IF X0<39 THEN X0=39 
3020 IF Y0<1 THEN Y0=1 
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f 3030 IF YG>245 THEN Y0=245 } 

5035 Z=0 I _ 

3040 IF MY0< 1 OR MY0>240 THEN MY0=1 > 

3042 IF MX0C40 OR MX0>210 THEN MX0=40 

^ 5045 MISSILES* (MYOS) =ERASE* _^ 

3050 D1=0:REM TURN OFF MISSILE SOUND 

3060 FIRE0=0:REM TURN OFF FIRE FLOG 

3080 TRAP 3000:GOTO 300 

10000 REM MISC. INITIALIZATION 

10050 J0YSTICK=632:HP0SP0=53248:PRIOR= 

623:M0VELEGS=30:SP=1:PR=8: BUTT0N0=644: 

SETS0UND=1000:S0=53760 

10060 BUTT0N0=644:SETSOUND=1000:80=537 
60:DV0=53761:HP0SM0=53252:HP08M0=53252 
:MS0=6 


10070 P1=10:D1=0:SD1=55 762:DV 1=53763:S 
I Z EM=53260 : RAND0M=53770 :\SY=2 J 
10900 RETURN ^- 

10999 REM PNG SETUP ROUTINE _ 

11000 DIM FILLER1* < 1) , FILLER2* ( (INT (AD~\ 
R(FILLERl*)/2048)+1)*2048-ADR(FILLER1* 
)-l) 

11010 DIM ERASE*(256),FILLER3*(256),FI 
LLER4*(256),MIBSILES*(256),PLAYERO*(25 
6 ) 

11020 ERASE*=CHR*(0) 

11030 ERASE*(256)=CHR*(CO 
11040 ERASE*(2)=ERASE*^RETURN 


11045 MISSILES*=CHR*(0):MISSILES*(256) 
=CHR*(0):MISSILES*(2)=MISSILES* 


(1104 
1 HR* ( 


047 PLAYERO*=CHR*(0):PLAYERO*(256)= 
0):PLAYERO*(2)=PLAYERO* 


11050 DIM LlEGS 1 * ( 1 7) , LEGS2* (17), LEGS3* 
(17) 

11060 FOR 1=1 TO 17:READ A:LEGS1*(1,1) 
=CHR*(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(1,1) 
=CHR*(A):NEXT I 

11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 
=CHR*(A):NEXT I 



11080 POKE 54279,ADR(ERASES)/256:REM D 
TELL ANTIC WHERE START OF PM MEMORY IS 


w9,46+16: REM SINGLE LINE 


11085 POKE Lw , , ___ _ . 

i RESOLUTION __ ___ ' 

*11090 POKE 53. 277.5: REM TURN ON PMG 
r11095 RETURN ^ 

11110 Pflk'ET'Rl OR, PR 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36,102,0,0,0 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 

6,72,132,130,0,0,0 _ 

1 11330 DATA 0,0,0,0,0,0,3,0,0,0,0,0,0^ 

11999 REM DRAN PLAVFIELD -- J 

12000 SETCOLOR 4,16,2:COLOR 1 
12010 PLOT 0,20:DRAWTO 40,20 

12020 COLOR 3:DRAWTO 60,35:COLOR 2:DRA 
WTO 79,35 
12030 RETURN 

12999 REM SET .PLAYER COLOR AND 
POSITION 

13000 X0=120 
13010 Y0=43 
13020 POKE 704,88 

13030 POKE 53248,XO:REM POKE HORI¬ 
ZONTAL VALUE INTO HORIZONTONAL POSIT 10 
N REGISTER. 

13040 PLAYER0*(Y0)=LEGS1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAVERO. VO 
DETERMINES VERTICAL POSITION 
13050 RETURN 

14000 ? "To fire missile., move joystic 
k end push fire hut ton RETURN 








Detecting Collisions 


Suppose a player fires a missile at an alien attacking space craft. Wouldn't it be 
nice to have a simple way to tell when there is a collision between the missile 
and alien ship? Or suppose you're making a maze game. Would you like to be 
able to detect when a player touches a maze wall? 


COLLISION DETECTION REGISTERS 

You can. Collision detection is easy with PMGI The Atari engineers wisely 
provided several collision detection registers for this purpose. Here they are: 

Missile Collisions 

Memory Location Shows: 

53248 Missile 0 to playfield collision 

53249 Missile 1 to playfield collision 

53250 Missile 2 to playfield collision 

53251 Missile 3 to playfield collision 


117 



118 / Detecting Collisions 


53256 Missile 0 to player collision 

53257 Missile 1 to player collision 

53258 Missile 2 to player collision 

53259 Missile 3 to player collision 

Player Collisions 

Memory Location Shows: 

53260 Player 0 to player collisions 

53261 Player 1 to player collisions 

53262 Player 2 to player collisions 

53263 Player 3 to player collisions 

53252 Player 0 to playfield 

53253 Player 1 to playfield 

53254 Player 2 to playfield 

53255 Player 3 to playfield 

ASSIGNING VARIABLE NAMES 

To simplify your programming task, I recommend that you assign a variable 
name to each collision register you need to use. It's a lot easier to keep track of 
variable names than all those memory locations.* 

Atari recommends variable names such as these: 

MOPF (missile 0 to playfield collision) 

M1PF (missile 1 to playfield collision) 

In the demonstration program in this chapter we will be using two 
collision registers: MOPF and POPF. 

■ What register do you think POPF refers to? 


*Later, though, you may wish to go back to using constants (such as 53260, 53261, etc.). That's 
because Atari BASIC only allows you 128 variable names. Also, statements with constants actually 
execute slightly faster than those using a corresponding variablel (This is not true with other 
computers such as the PET and Apple, where variables execute 10 to 40 times faster than con¬ 
stants.) I'd like to thank B. B. Garrett for clarifying this in his informative article "Atari Times" in the 
May, 1983 issue of Computel 
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ANSWER 

Player 0 to playfield collision (53252) 

If you have the program from the previous chapter loaded into memory, 
you might want to initialize POPF and MOPF right now by adding these state¬ 
ments to line 10070: 

P0PF=53252: 

M0PF=53248 

READING COLLISION REGISTERS 

You can read a collision register with a peek command. For example: 

COLLISION=PEEK(POPF) 

After this statement executes, COLLISION will contain either 0,1,2, or 4. 

In our sample program you will find that: 

• If POPF contains a zero, then there was no collision. 

• If POPF contains a 1, then PLAYER 0 collided with that part of the 
playfield drawn with COLOR 1. 

• If POPF contains a 2, then PLAYER 1 collided with that part of the 
playfield drawn with COLOR 2. 

• If POPF contains a 4. then PLAYER 1 collided with that part of the 
playfield drawn with COLOR 3. 

Ok, try this one. Suppose you draw a line on the screen with these 
statements: 

GRAPHICS 7: 

SETCOLOR 2,3,4: COLOR 3: 

PLOT 0,0: DRAWTO 159,0 

Furthermore, suppose you read a collision register like this: 

COLLISION=PEEK(POPF) 


■ What value will be in COLLISION if player 0 is touching the line you drew? 
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ANSWER 

4 (a 4 shows a collision with a playfield drawn with COLOR 3). 


MULTIPLE COLLISIONS 

Once a collision occurs, the collision register retains the number that was 
placed in it. If a second collision occurs, the next number is added to the 
number that already exists there. 

■ Suppose player 0 collides with a playfield drawn with COLOR 1 and then 
collides with a playfield drawn with COLOR 3. What value will be the 
collision register? (Careful now, this one is a bit tricky.) 


ANSWER 

5 (the 1 from the first collision will be added to the 4 from the second 
collision). 


CLEARING COLLISION REGISTERS 

Since the collision registers retain the values put in them when a collision 
occurs, it's important to reset them. This is almost as easy as taking candy from 
a baby. All you do is poke a 1 into the HIT CLEAR register at location 53278. 

I suggest you use a variable for the HIT CLEAR register. Let's call it HITCLR. 
At line 10070 insert this statement: 

HITCLR=53278 

Often we think of clearing something by poking zeros in it. But this is 
different; here we are turning on the hit clear switch. That's why we poke it 
with 1 rather than 0. 


■ When we poke a 1 into HITCLR what do you think happens? 

a. All collision registers are cleared. 

b. Only selected registers are cleared. 
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ANSWER 

You're right if you said "a. All collision registers are cleared." 


USING COLLISION REGISTERS 

Often programmers peek at the collision registers and then use a series of 
IF-statements to decide on what action to take. But there's a much better way. 
Remember, in Atari BASIC you can GOSUB a variable or even GOSUB a 
PEEKED value! We did this in our joystick routine, and we can also do it with 
collision registers. 

■ Suppose we want to execute a subroutine that starts at line 41 if player 0 
collides with a COLOR 1 playfield.* Write a statement to make that 
happen. (GOSUB the value in POPF plus an offset.) 


ANSWER 

GOSUB PEEK(P0PF)+40 


■ Now suppose player 0 hits a COLOR 3 playfield. At what line number 
must we have a subroutine to handle this possibility? 


ANSWER 

We need a subroutine at line 44. That's because POPF will contain a 4 if 
player 0 hits a COLOR 3 playfield. 


DRAWING A PLAYFIELD 

Now let's use some of these techniques in a PMG program. First, let's draw a 
playfield. We'll make it a maze so that in a later chapter we can expand the pro¬ 
gram into a full-fledged game. 


•In this book, a COLOR I playfield is simply a playfield drawn with COLOR 1. The 
term "playfield i," as used in the Atari technical manual, is not synonymous with the 
term "COLOR 1 playfield." 
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We've already reserved lines 12000-13000 for drawing a playfield, so let's 
put our new playfield subroutine there. (Note that we need to delete the 
previous playfield, which was contained in lines 12000, 12010, 12020, and 
12030.) 

Here are the lines for the new playfield subroutine. I suggest you enter 
them now. 


11999 REM BRRH PLR'/FIELD 

12000 SETCOLOR 2,3,4:COLOR 1 

12010 PLOT 0,0:DRAWT0 159,0:DRAWTO 159 
, 79: DRAWTO 0,79:DRAWTC) 0,0 
12015 COLOR 2 

12020 PLOT 80,61: DRAWTO 80,79: PLOT 0,6 
o: DRAWTO 30,60: DRAWTO 30,79 
12025 COLOR 3 

12030 PLOT 52,60:DRAWTO 52,45:DRAWTO 1 
10,45:DRAWTO 110,60:DRAWTO 137,60:DRAW 
TO 137,45:DRAWTO 110,45:PLOT 159,32 
12040 DRAWTO 110,32:PLOT 80,45:DRAWTO 
80,20:PL0T 130,16:DRAWT0 130,14:DRAWTO 
127,14:DRAWTO 127,16:DRAWTO 130,16 
12050 PLOT 43,0:DRAWTO 43,30:PLOT 52,4 
5:DRAWTO 22,45:DRAWTO 22,13:PLOT 103,0 
:DRAWTO 103,17:POKE 559,34:RETURN 


Also, let's revise lines 2010 and 2015 so that line 2010 becomes 2015 and 
2015 becomes 2010. It seems that PMG works better when the playfield is 
drawn before the PMG setup is executed. 

And at line 2005 change GRAPHICS 5 to GRAPHICS 7 since our new 
playfield requires that graphics mode. 


REVISING THE MAIN LOOP 

Now let's revise the main loop of our program so that it detects when our 
player touches the sides of the walls. First, change line 200 into line 201. Do this 
so that we can create some new collision detection routines at line 200. 

Now at the beginning of line 200, let's simply print the contents of the 
collision register—just so we can see what they contain when various objects 
collide. This is easy to do, like so: 

? “P0PF=”;PEEK(P0PF), 

“M0PF=”;PEEK(M0PF) 
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Next, also at line 200, let's call for the execution of the two collision detection 
subroutines, one for POPF and one for MOPF. And let's arrange things so that if 
there is no collision, we immediately return from each subroutine. We'll let the 
POPF subroutine start at line 40 and the MOPF subroutine start at line 50. 

Here's the call to the MOPF subroutine: 

GOSUB PEEK(M0PF)+40: 

■ Now you write the call to the POPF subroutine: 


ANSWER 

GOSUB PEEK(P0PF)+50 

Altogether then, line 200 will look like this: 

200? “P0PF=”; PEEK (POPF), 
“M0PF=”; PEEK (MOPF): 
GOSUB PEEK(M0PF)+40: 
GOSUB PEEK(P0PF)+50 


PLAYER-PLAYFIELD COLLISIONS 

Simple right? Now all we need to do is decide what we want to happen when 
a collision occurs. For now, let's fix things so that our player cannot walk 
through the maze walls. Here's how we'll do it. At the beginning of line 201 
we'll save the X0 and Y0 coordinates by inserting the statement X0A=X0 and 
Y0A=Y0: 

201 Y0A=Y0:X0A=X0: 

GOSUB PEEK(JOYSTICK): 

GOSUB MOVELEGS 

Then when our player hits a maze wall, we'll reset X0 and Y0 back to what they 
were before the collision. Got it? 

Suppose our player hits a COLOR 1 playfield. Then POPF will contain a "I," 
and control will pass to line 41 (as a result of GOSUB PEEK (POPF)+40). Then at 
line 41 all we need to do is: 
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1. Set the YO and XO coordinates to what they were before the collision. 

2. Clear the collision registers by poking a 1 into HITCLR. 

■ See if you can write the code for line 41: 


ANSWER 

41 X0=X0A:Y0=Y0A:PQKE HITCLR, 1:RETURN _ 

We also need this same subroutine at line 42. That's because POPF will 
contain a 2 if our player hits a COLOR 2 playfield. 

If our player hits a COLOR 3 playfield, POPF will contain a 4 (strange as 
this may seem). 

■ So what line will be executed if our player hits a COLOR 3 playfield? 


ANSWER 


44 (Since 40+4=44.) 


■ So what code do we need at line 44? 


ANSWER 

44 XO=XOA:YO=YOA:POKE HITCLR.l:RETURN 

Let’s look at the playfield detection statement more closely. It is: GOSUB 
PEEK(M0PF+40). 

■ If the player does not hit anything, POPF will contain a zero. So where will 
control pass when the playfield detection statement is executed? 


ANSWER 

Control will pass to line 40 (0+40=40). 
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■ What code would be appropriate for line 40? (Hint: we don't really need 
to do anything since no collision has occurred. All we need to do is get 
back to the main loop.) 


ANSWER 

All we need is a RETURN statement at line 40. This will return control to the 
main loop. 


MISSILE COLLISIONS 

The missile collision subroutines start at line 50 since the calling routine is 
GOSUB M0PF+50. If no missile-playfield collision has occurred, we won't need 
any specific action. 

■ What will the code be for line 50? 


ANSWER 

50 RETURN 

If a missile hits a wall, we will want to do these things: 

• Move the missile off the screen by poking zero into HPOSMO. 

• Turn off the missile sound. 

• Turn off the missile move indicator (FIRE0). 

• Clear the collision registers. 

■ Since we will have to do this whenever a missile hits a wall, let's put it into 
a subroutine at line 190. See if you can write the code: 


190 POKE HPOSMO,0: 
D1=0: 


ANSWER 
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FIRE0=0: 

POKE HITCLR.1: 
RETURN 


■ Now if a missile hits playfield 1, to which line will control pass? 


ANSWER 

51 (MOPF will contain 1.1+50=51) 

■ What additional line numbers will we need for playfields 2 and 3? 


ANSWER 

We'll need line 52 and line 54. (Remember, if a missile hits playfield 3 then 
the collision register will contain a 4.) 

Line 190 contains the commands that we want executed if a missile hits a 
wall so at line 52 all we need is: 

52 GOSUB 190:RETURN 

Similarly, at lines 53 and 54 we'll use the same code: 

53 GOSUB 190:RETURN 

54 GOSUB 190:RETURN 

TRY IT 

Make all the changes I've discussed so far to MISSILE.SAV. Also, change line 2 
to: 


SAVE “D:MISSCOL.SAV”:STOP 

All the changes are summarized in the listing that follows: 

1 TRAP 3000:GOSUB 2000:GOTO 200 _ 

I 2 SAVE "D: MISSCQL. SAV" : STOP : REM DISK 

V _ ___ 

4 REN ADJUST HORIZONTAL & VERTICAL 
COORDINATES 
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5 xo=xo+sp:yo=yo+sp:return 

6 yo=yo-sp:xo=xo+sp:return 

7 XO=XO+SP:RETURN 

9 XO=XO-SP:YO=YO+SP:RETURN 

10 xo=xo-sp:yo=yo-sp:return 

11 xo=xo-sp:return 

13 yo=yo+sp:return 

14 Y0=Y0-SP:RETURN 

15 POP :PLAYER0$(Y0)=LEGS1*:G0T0 300 

29 REM MOVE PLAYER'S LEGS 

30 Z=Z + l:POKE HPOSF'O, XO: IF Z<4 THEN PL 
AYERO$(YO)=LEGS1*:RETURN 

31 IF Z<7 THEN PLAYERO* (YO) =LEGS2$: RET 
URN 

32 PLAYER0$(Y0)=LEGS3$:IF Z=9 THEN Z=0 
:RETURN 

33 RETURN _ 

40 RETURN\ 

41 XO=XOA:YO=YOA:POKE HITCLR,1:RETURN ' 

42 xo=xoa:yo=yoa:poke HITCLR,i:return 
44 xo=xoa:yo=yoa:poke HITCLR,1:return 

49 REM MISSILE 0 TO PLAYFIELD 

50 RETURN 

51 GOSUB 190:RETURN 

52 GOSUB 190:RETURN 

53 GOSUB 190:RETURN 

54 GOSUB 190:RETURN 

V 60 REM END OF COLL I SI OHS __ 

65 MXO=MXO+MSO:MYO=MYO+MSO:RETURN 

66 MYO=MYO—MSO:MXO=MXO+MSO:RETURN 

67 MXO=MXO+MSO:RETURN 

69 MXO=MXO-MSO:MYO=MYO+MSO:RETURN 

70 MXO=MXO-MSO:MYO=MYO-MSO:RETURN 

71 MXO=MXO-MSO:RETURN 

73 MYO=MYO+MSO:RETURN 

74 MYO=MYO-MSO: RETURN ___ 

[ 190 POKE HPOSMO,0:D1=0:FIRE0=0:POKE HI' 

1 TCLR,l:RETURN ___ 

199 REM MAIN LOOP 
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r 200 ? "POPF=";PEEK(POPF),"MOPF=";PEEK( 
MOPF):GOSUB PEEK<POPF)+40:GOSUB PEEK(M 
OPF)+50 

201 Y0A=Y0:XOA=XO:GOSUB PEEK(JOYSTICK) 
i :GOSUB MOVELEGS 


260 REM 
270 REM 
280 REM 
290 REM 

300 POKE SD1,P1:POKE DV1,D1SPOKE SIZEM 
,PEEK(RANDOM) 

301 IF PEEK(BUTTONO)=0 AND PEEK(JOYSTI 
CK)< >15 THEN MOVEO=PEEK(J OYSTICK):FIRE 
0=FIREO+1 

305 IF FIRE0=0 THEN GOTO 200 

315 IF FIRE0=1 THEN MX0=X0+3:MY0=Y0+7: 

DIRO=MOVEO:FIREO=FIREO+1:D1=15 

320 IF FIREOM THEN GOSUB DIR0+60 

330 D1=D1-1:IF Dl<1 THEN D1=0 

335 MISSILES$=BUFFER*:POKE HPOSMO,MXO: 

MISSILES^ <MYO)=MIMAGE0$ 

499 GOTO 200 

600 GRAPHICS OrTRAP 610:FOR 1=1 TO 128 
:? IS" "S ASC(PLAYERO$(I)):NEXT I:STOP 




610 END 

1999 REM SETUP ROUTINES FOLLONs 

2000 GOSUB 10000:REM MISC. IN1TIALI- 


2005 GRAPHICS 7:REM SET 6R. 
BEFORE PMG SETUPf 


MODE 


2 


010 GOSUB 12000:REM DRAM PLOYFIELD ] 

;015 GOSUB 11 OOP: REM PMG SETUP _ J 

2020 GOSUB 13000: REM PLOVER COLOR 7TND 
SCREEN POSITION 

2025 GOSUB 14000:REM DISPLAY MESSAGE 
2130 RETURN 

2999 REM ERROR CORRECTION ROUTINE 

3000 IF X0>210 THEN X0=210 
3010 IF X0<39 THEN X0=39 


3020 IF Y0<1 THEN Y0=1 
3030 IF Y0>128 THEN Y0=128 
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3035 2=0 

3040 mxo=xo:myo=yo 

3050 D1=0 

3060 FIRE0=0 

3080 TRAP 3000:GOTO 300 

10000 REM MISC. INITIALIZATION 

10050 J0YSTICK=632:HP0SP0=53248:PRIOR* 

623:M0VELEGS=30:SP=1:PR=8:BUTT0N0=644: 

SETS0UND=1000:S0=53760 

10060 BUTT0N0=644:SETSOUND*1000:S0=537 
60:DV0=53761:HP0SM0=53252:HP0SM0=53252 

:MS0=6 _ 

' 10070 P1 = 10:D1=0:SD1=53762:DV1=53763:S 
IZEM=53260:RAND0M=53770:P0PF=53252: MOP 
F=5324S:HITCLR=53278:POKE HITCLR,1 

V-.-----__ 

10900 RETURN 

10999 REM PNG SETUP ROUTINE 

11000 DIM FILLER1*(1) ,FILLER2*((INT(AD 
R(FILLER1$)/1024)+1)*1024-ADR(FILLER1 $ 
>-l) 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO*(128),PLAYER1*(128),PLAYER2*(1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER* < 2)=BUFFER* 

11045 MISSILES*=BUFFER*:PLAYERO*=BUFFE 
R$: PLAYER 1 *=BUFFER*: PLAYER2*=BUFFER*: F' 
LAYER3*=BUFFER* 

11050 DIM LEGS1*(17),LEGS2*(17) ,LEGS3* 
(17) 

11060 FOR 1=1 TO 17:READ A:LEGS1*(I,I) 
=CHR*(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(1,1) 
=CHR*(A):NEXT I 

11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 
=CHR*(A):NEXT I 

11070 DIM MIMAGEO*(1):MIMAGEO*=CHR*(3) 

11080 POKE 54279,ADR(BUFFER*)/256:REM 
DTELL ANTIC WHERE START OF PM MEMORY I 
S 

11085 POKE 559,46:REM DOUBLE LINE RES. 
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11090 POKE 53277,3:REM TURN ON PMG 
11110 POKE PRIOR, PR- 

11299 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36,102,0,0,0 

11310 DATA 0,0,0,28,20,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72,132,130,0,0,0 

11999 REM DRAM PLAY FI ELD __—^ 


12000 SETCOLOR 2,3,4:COLOR 1 A 

12010 PLOT 0,0:DRAWT0 159,0:DRAWT0 159 
,79:DRAWTO 0,79:DRAWT0 0,0 
12015 COLOR 2 

12020 PLOT 80,61:DRAWTO 80,79:PLOT 0,6 
0:DRAWTO 30,60:DRAWTO 30,79 
12025 COLOR 3 

12030 PLOT 52,60:DRAWTO 52,45:DRAWTO 1 
10,45:DRAWTO 110,60:DRAWTO 137,60:DRAW 
TO 137,45:DRAWTO 110,45:PLOT 159,32 
12040 DRAWTO 110,32:PLOT 80,45:DRAWTO 
80,20:PLOT 130,16:DRAWTO 130,14:DRAWTO 
127,14:DRAWTO 127,16:DRAWTO 130,16 


’ 12050 PLOT 43,0:DRAWTO 43,30:PLOT 52 
5:DRAWTO 22,45:DRAWTO 22,13:PLOT 103 
:DRAWTO 103,17:POKE 559,34:RETURN 
12999 REM SET PLAYER COLOR AND 
POSITION 


A 


13000 X 0=175^ 
.13010 Y0=80 > 


G 


13020 POKE 704,88 

13030 POKE 53248,XO:REM PONE HORI¬ 
ZONTAL OALUE INTO HORIZONTONAL 
POSITION REGISTER. 

13040 PLAYERO$(YO)=LEGS1$:REM PUT 
IMAGE INTO PROPER BYTE OF PLAYERO. YO 
DETERMINES VERTICAL POSITION 

13050 RETURN _ 

14000 ? "Collision Demo.": FOR PAUSE= 
TO 100:NEXT PAUSE:RETURN 


3 
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Save the program and then run it. Note: I suggest you push the RESET 
button each time before you run the program; this will ensure that the PMG 
image appears correctly when the program first starts. As you move the player 
against the various walls of the maze, notice the values that appear in POPF. 

Next try firing the missile in various directions. Notice that sometimes the 
missile will hit a wall. When this happens, the missile sound stops and the 
missile disappears. The player can now immediately fire another missile. 

Sometimes the missile will go right "through a wall." That's because the 
missile is moving in increments of 6. Actually, the missile is "hopping over the 
walls"—it really never touches the wall—hence there is no collision. This could 
be fixed by making the walls thicker or the missile bigger. Or the missile 
coordinates could be adjusted by I instead of 6. Of course, then the missile 
would probably move too slowly for most purposes. 

Yet another approach would be to use an assembly language routine to 
move the missile.* In the programs in this book we'll simply let the missile pass 
through walls. In a game situation, this effect is good because you never know 
when one of your missiles will be "super-charged" and capable of passing 
through a wall. 

SLOW PLAYER MOVEMENT 

Notice that the player moves rather slowly. That's mainly because we are 
constantly peeking at and printing the values contained in the collision regis¬ 
ters. You can speed up the player's movement considerably by deleting 
?P0PF=";PEEK(P0PF) and ?M0PF='';PEEK|M0PF) in line 200. 

Of course part of the reduction in the player's speed results because the 
main loop is becoming more complicated. Remember, we are doing quite a bit 
in this little BASIC program. We have created: 

• Vertical, horizontal, and diagonal movement 

• Leg animation 

• Missile firing and movement in eight directions 

• Random missile-size selection 

• Explosive missile sound 

• Player and missile collison detection. 


*Watch for my next book on advanced PMG techniques. In it I'll show you how to use machine 
language subroutines to speed up your PMG programs. 
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But with player-missile graphics, once we have come this far, it's easy to add 
even more "features." 


ADDING MORE FEATURES 

Let's try something a little different. Let's pretend that the COLOR 1 playfield has 
an electrical charge that will zap our player if he touches it. To produce the 
"zapping effect," let's produce a strange sound and flash several colors through 
the player when he touches playfield 1. Furthermore, let's set our player to a 
random new color and then put him back to his starting location. The code to 
do this is relatively simple and won't slow down the main action. That's 
because the code will not be in the main loop but in subroutines that will 
execute only when a collision occurs. 

Here's the new code to "zap" the player when he touches the COLOR 1 
playfield. Change line 41 to: 

41 X0=175:Y0=80: 

GOSUB 400: 

POKE 704, PEEK (RAN DOM): 

PLAYERO$=BUFFER$: 

POKE HPOSPO.XO: 

POKE HITCLR.1: 

RETURN 

And add lines 400 and 410: 

400 FOR 1=0 to 100 STEP 2: 

POKE 704,1: 

SOUND 0,1,10,15: 

SOUND 1,1+50,10,15: 

NEXT I 

410 SOUND:RETURN 

Also change line 499 to line 390 so that line 390 reads "GOTO 200." 

As you can see the subroutine at line 400 rapidly moves different values 
into player 0's color register. This causes him to "glow." In the same loop we 
also include a nice sound effect with the aid of a couple of SOUND statements. 
(I used SOUND statements, here, rather than poking audio control registers, 
because SOUND statements are easier to use. Remember, speed is not so 
important here since we are not in the main loop. When a player is zapped, it's 
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natural for the action to stop. All attention is focused on the zapped player, 
anyway.) 

There you have it. Collision detection complete with a fancy routine to 
zap a player and move him back to his starting location if he hits a specific kind 
of playfield. 

In the next chapter we'll pull together everything you've learned so far 
and create "MAZEDUEL," a racing game in which two players compete for a 
dangerous but valuable "crystal." 





Programming a Game 


In this chapter I'll show you howto use the techniques you've learned to write 
an arcade-style game. It doesn't have the speed of a machine language pro¬ 
gram, but thanks to Atari's PMG it contains a lot of action-packed features: 
animated players, sound effects, missiles, lasers, collision detection, and flash¬ 
ing colors. And best of all, since you've come this far, you'll be able to modify it 
to your liking. Before you know it, you'll be creating your own original gamesl 


MAZEDUEL 

Let's call the game "Mazeduel" since two players will be fighting it out as they 
chase each other around a maze. I'll go over the rules of the game first and 
then discuss the programming techniques. 

Winning a round. The game will have rounds (sort of like a boxing match). 
In the upper right corner of the maze you'll see a magic crystal. If a player 
touches the crystal, an alarm will sound as the screen flashes different colors. 
The player who touches the crystal wins the round and is awarded five points. 
Both players will then be moved back to the starting box. 


135 
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A player can also win a round by hitting the crystal with a missile. In this 
case, however, that player gets only one point. 

Firing missiles. Players can fire missiles at each other. Missiles contain a 
strange substance that causes players to instantly expand to double size if they 
are hit. If a player expands to double size, he stays that way until the other 
player gets zapped. 

If you are hit by a missile you will be zapped back to the starting box and 
enlarged to double size. You get one point for hitting another player with a 
missile. 

Maze walls. You must exercise extreme caution when moving around the 
maze. Ifyou touch a maze wall, you are also zapped back to the starting box 
and enlarged to double size. In addition, the other player will gain a point. 

Beware of the crystal. The crystal is harmless—unless you try to win a 
round by touching it. When the crystal's defense system is activated, it may 
send out a storm of laser-type missiles. Ifyou are quick enough though, you 
may be able to avoid the lasers. But ifyou don't, you will again be expanded to 
double size and zapped back to the starting box. Another penalty is that the 
other player will gain one point. The lasers destroy any part of the maze that 
they hit, but only stun players. As the maze starts to break up more and more, 
you will find it easier to sneak up on the crystal. 

It's possible for a player to escape from the maze and sneak up on the 
crystal while "offscreen." (I won't tell you how.) Be alert when hiding behind 
maze walls. Missiles fired by players sometimes penetrate walls! To fire a 
missile, move the player in the direction you want the missile to go and press 
the fire button. The first player to get ten or more points wins. You can start a 
new game by pressing your fire button. 

Selecting colors. At the beginning of each game, you can select the color of 
the playfield by pressing the SELECT key. Just keep pressing it (or hold it down) 
until you get a color you like. When you're ready to start the game, press the 
START key. 

To select colors for players, press the OPTION key. 

As usual, the complete listing appears at the end of this chapter. You may 
wish to load the program from the previous chapter, MISSCOL.SAV, and then 
modify it to produce MAZEDUELSAV. I've made a lot of modifications, how¬ 
ever, and it may be just as easy to type it in from the start. 
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For maximum execution speed, don't type in any of the REM statements. 

I included them to help you understand the program (and to help myself keep 
track of what I was doing). 

Again, the subroutine beginning at line 2000 takes care of calling the 
various setup subroutines. Here are the setup subroutines along with their 
beginning line numbers: 

10000 Initialize Constants 

12000 Draw Playfield 

11000 Set up PMG 

13000 Specify player colors and initial position (off screen) 

5000 Allow users to select colors 

Note that line 10000 is no longer a REM statement. If it were, the GOSUB 
10000 statement at line 2000 would produce an error if you were to delete the 
REM statements. 

In the 13000 subroutine, at line 1345, I poke PLAYER1S with the data in 
LEG1S. Remember, PLAYER1S is the PM memory area for our second player. 
PLAYER0S is the memory area for our first player. To simplify the programming, I 
made both players have exactly the same image. (They are easy to tell apart, 
because each has its own color.) 

Notice that in the subroutine starting at line 5000,1 move the players onto 
the screen and display a message in the text window. Location 53279 tells me 
which of the console keys have been pressed. When 53279 contains a 6, I 
know the user has pressed the START key and it's time to return from this 
subroutine. 

Control then returns to the "executive" setup subroutine at line 2000. I 
call the subroutine at line 2000 an "executive" because it controls other sub¬ 
routines rather than carrying out any direct action of its own. After the last 
subroutine within the executive setup subroutine, control returns to line 1. From 
there we jump to the main loop at line 200. 

CHECKING FOR COLLISIONS 

Lines 200 and 201 now check for the various collisions. Notice how easy this is. 
We simply call various subroutines. The subroutine called depends on the 
contents of the appropriate collision register. For example, look at the first 
statement in line 200: 
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GOSUB PEEK(P0PF)+100 

■ If the player 0 to playfield collision register (POPF) contains a zero, meaning 
no collision, which subroutine will be executed? 


ANSWER 


The one at line 100 (0+100=100). 

So at line 100 we put a RETURN statement. Now, the magic crystal was 
drawn using COLOR 2. So the magic crystal is considered a "COLOR 2 play- 
field." 

■ Suppose player 0 touches the crystal. Which subroutine will be executed? 


ANSWER 


The one at line 102 (2+100=102). 

The other collision detection subroutine calls work the same way. Slick, 
huh? And much faster than IF-statementsI* 


MOVING LEGS 

At line 204 we check to see if joystick 0 has been moved. JO is now a variable 
initialized to 632, the memory location that contains the value for joystick 0. If JO 
is not equal to 15 (uprightjoystick), then I add 1 to Z. Z will now be equal to 1. At 
this point, I GOSUB line 35 (34+Z will equal 35). Line 35 moves LEG1S data into 
PLAYER0S. The next time through the main loop, line 204 will call the sub¬ 
routine at line 36 (since Z will now be equal to 2). 

This is similar to the earlier leg movement routine. I modified the earlier 
routine to make it easier to handle the movement of two separate players. 

If the joystick is not moved, then control will pass to line 205. At line 2051 
simply move the "standing still" image of player 0 into PLAYER0S. I do a similar 
thing for player 1 at lines 206 and 207. 


‘I'd like to thank my son, Dan Seyer, for suggesting this collision detection method. 
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CRYSTAL DEFENSE SYSTEM 

Control now passes to the ciystal defense system at line 210. Notice that I am 
using the random number generator at location 53770. (RANDOM is initialized 
to 53770.) If RANDOM contains a number greater than 220 then we check to 
see if either of the players has entered the ciystal's attack zone. We know a 
player is in the crystal's attack zone if its X coordinate is greater than 142 and its 
Y coordinate is less than 34. During game development, you can easily discover 
the coordinates fora specific location by positioning a player where you want 
him, hitting the break key, and then printing the coordinates. 

Why the check of the random number? Well, this way the crystal's 
defense system isn't perfect. Sometimes a player will be able to sneak past it 
and reach the crystal before it starts wildly firing lasers in all directions. By 
changing 220 to some other number, you can increase or decrease the proba¬ 
bility that a player will be able to sneak in and touch the ciystal. The higher the 
number (up to 255) the better the player's chances will be. (By the way, 
location 53770 generates a random number between 0 and 255.) 

If all conditions are satisfied, then the laser firing routine is activated 
starting at line 450. This is a fairly simple routine, but the results are quite 
dramatic. In this routine I use DRAWTO statements to create the lasers. A nice 
effect is produced by drawing the various random vertical coordinates. Again I 
used location 53770 to set a variable called VT to various values. VT is then 
used in the DRAWTO statement as the vertical coordinate. Notice that I use 
COLOR 1 when drawing the laser. The collision detection routine is already set 
up to detect a collision with anything drawn with COLOR 1. So if the laser hits 
the player, zapo-whamo! After drawing a laser, I erase it by redrawing it using 
COLOR 0. 

After the crystal defense check at line 210, control passes on to the missile 
move routine at 300. 


MISSILE MOVE ROUTINE 

This routine is quite similiar to the one in the previous chapter, except that now 
we have to deal with two missiles. This can present a problem when two 
missiles are both fired at the same time. The binary image data for missile 0 is: 

00000011 (or 3 in decimal) 

For missile 1, the binary data is: 

00001100 (or 12 in decimal) 
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Suppose both missiles happen to occupy the same byte in missile memory. 
(This will happen whenever MY0=MY1.) 

■ What if we move 00000011 into byte 22 of MISSILES and then immediately 
move 00001100 into that same byte of MISSILES? What will be the effect on 
missile 07 


ANSWER 

Missile 0 will disappearl That's because the zeros in the far right bit position 
of missile 1 will take the place of the l's that were there before. 

Look again at the binary data: 

Missile 0: 00000011 
Missile 1: 00001100 

This can be solved with a machine language subroutine that addresses 
specific bits. That is, if we wanted to turn on missile 0, we would turn on only 
the two bits on the far right. But we would not move zeros into the other bits. 

In BASIC we cannot address specific bits. That is, we cannot move data 
only into certain bits, but not others. In BASIC we must deal in bytes. 

My solution to the problem was to "turn on" both missiles whenever 
both missiles happened to occupy the same byte in missile memory. I did this 
by initializing a variable called BMISSS to 15. Then at line 335 I check to see if 
MX0=MX1. If MXCNMX1,1 jump to line 400 where I move 15 into MISSILES. 

■ Why does putting a decimal 15 into MISSILESS turn on both missilesS? 


ANSWER 

Because in binary, 00001100 + 00000011 = 00001111 and 00001111 = a decimal 
15. 


Now if MY0 does not equal MY1, the missiles are not destined to occupy 
the same byte in missile memory. Consequently, I move the missile data for 
each missile with separate statements in line 340. 

Yes, the IF-statements do slow things down. You're right if you're think¬ 
ing that this is a good place for a machine language subroutine. (Look for it in 
my next book on PMG.) 

After the missile data is moved into the proper byte of MISSILES, control 
returns to line 200, the first line of the main routine. 
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TYPING IN THE PROGRAM 

The program listing appears at the end of this chapter. It may look long, but 
remember, a lot of it is a duplication of the code from the previous chapter. 

As I mentioned earlier, it's probably a good idea to omit all REM state¬ 
ments when typing in the program. It will require less memory this way and 
run faster. The program will fit into a 16K cassette system ora disk drive system 
with 24K. 

Since this program was designed for instructional purposes, more line 
numbers are used than actually needed. You can speed up the program 
somewhat by combining some lines. For example, line 330 could be combined 
with 335. But be careful in doing this. For example, don't try to combine two 
IF-statements. Ifyou do, then the second IF-statement won't execute unless the 
first condition is true. For best results, I suggest you type in the program exactly 
as is. Then after you've saved a working copy, you can doyourthingl Have fun. 
Here are some revision suggestions: 

1. Make the crystal more interesting by creating him with PLAYER2S. You 
can put PLAYER2S right on top of (or underneath) a playfield. 

2. You could create a three-colored crystal by combining PLAYER2S with 
PLAYER3S (see the next chapter for details). 

3. If you make the crystal with PMG, then you can make it glow by 
poking different values into the appropriate color registers. You could 
also easily animate it or change its size, with just a few statements. If 
you do this at line 450 (the laser firing routine), you won't slow down 
the main loop. That's because line 450 executes only when a laser is 
fired by the crystal. 

4. Using the other players, you might want to have various alien crea¬ 
tures pop up in the maze and block the movement of the main two 
players. 

5. You may wish to experiment with changing the players to different 
sizes at different times. Here are the size registers: 

Player Number Size Register 

0 53252 

1 53253 

2 53254 

3 53255 


To set a player's size, poke the appropriate register with 0,1,2, or 3 as 
follows: 
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Value to Poke 
Player Size into Register 

Normal 0 or 2 

Double 1 

Quadruple 3 

So for normal player size, poke the appropriate register with zero or 2. 
For double player size, poke it with 1. For quadruple player size, poke it 
with 3. 

6. For faster action, you might want to try your hand at converting part of 
the program to machine language. MAZEDUEL is written entirely in 
BASIC. Again, look for my next book on PMG for hints on how to do 
this! In the meantime, I suggest you keep reading your favorite maga¬ 
zine for ideas. My favorites (in alphabetical order) are: Analog, Antic, 
Byte, Compute, Creative Computing, and Micro. 

Happy hacking. 

Congratulations. You've just about finished this book. By now, you've 
mastered most of the fundamentals of PMG—one of the most powerful and 
least understood features of the Atari computer. 

In the next chapter. I'll wrap things up (at least for now), by discussing a 
few additional PMG odds and ends. 

1 TRAP 3000:GOSUB 2000:GOTO 200 

2 SAVE "D:MAZEDUEL.SAV":STOP 

5 XO=XO+SP:YO=YO+SP:RETURN 

6 YO=YO-SP:XO=XO+SP:RETURN 

7 XO=XO+SP:RETURN 

9 XO=XO-SP:YO=YO+SP:RETURN 

10 xo=xo-sp:yo=yo-sp:return 

11 xo=xo-sp:return 

13 yo=yo+sp:return 

14 YO=YO-SP:RETURN 

15 RETURN :REM POP :PLAYERO$(YO)=LEGS1 
$:POKE DV0,0:G0T0 210 

16 xi=xi+sp:yi=yi+sp:return 

17 Y1=Y1-SP:X1=X1+SP:return 
is xi=xi+sp:return 

20 X1=X1-SP: Y1--Y1+SP: RETURN 

21 xi=xi-sp:yi=yi-sp:return 

22 X1=X1-SP:RETURN 
24 Y1=Y1+SP:RETURN 



Typing in the Program / 143 


25 Y1=Y1-SP:RETURN 

26 RETURN :REM POP :PLAYERO*(YO)=LEGS1 
*:POKE DV0,0:G0T0 210 

29 REM MOVE LEGS OF PLOVER 0 

35 PLAYERO*<YO)=LEGS1*:RETURN 

36 PLAYERO*< YO)=LEGS2*:RETURN 

37 PLAYERO*(YO)=LEG53*:Z=0:RETURN 
49 REM MOVE LEGS OF PLOVER 1 

55 PLAYER1*(Y1)=LEG51*:RETURN 

56 PLAYER1*<Y1)=LEGS2*:RETURN 

57 PLAYER1 $(Y1)=LEGS3*:W=0:RETURN 

65 MX0=MX0+MS0:MY0=MY0+MS0:RETURN 

66 MYO=MYO-MSO:MXO=MXQ+MSO:RETURN 

67 MX0=MX0+MS0:RETURN 

69 MXO=MXO-MSO:MYO=MYO+MSO:RETURN 

70 MXO=MXO—MSO:MY0=MY0—MSO: RETURN 

71 MXO=MXO--MSO: RETURN 

73 MYO=MYO+MSO:RETURN 

74 MYO=MYO-MSO:RETURN 

84 REM 013JUST MISSILE l 

85 MX 1=MX1+MSO:MY1=MY1+ MSO:RETURN 

86 MY1=MY 1 -MSO:MX1=MX1+MB0:RETURN 

87 MX1=MX1+MS0:RETURN 

89 MX 1=MX1-MSO:MY1=MY1+MSO:RETURN 

90 MX 1=MX1—MSO:MY1=MY1-MSO:RETURN 

91 MX1=MX1-MS0:RETURN 

93 MY1=MY1+MS0:RETURN 

94 MY1=MY1-MSO:RETURN 

98 REM COLLISIONS 

99 REM PLOVERO TO PLOVFIELD 

100 RETURN 

101 S1=S1+1:GOSUB ZAP:PLAYERO$=BUFFER$ 
:PLAYERO*(YO)=LEGS1 *:GOSUB 5500:RETURN 

102 S0=S0+5:GOTO 660:REM PLOVERO HITS 
CRVSTOL/ 

103 SI=S 1 +1:GOSUB ZAP:PLAYERO*=BUFFER* 
:PLAYERO*(YO)=LEGS1*:GOSUB 5500:RETURN 


104 RETURN 

105 RETURN 

106 RETURN 

107 Sl=Sl+l:GOSUB ZAP:PLAYERO*=BUFFER* 
:PLAYERO* <YO)=LEGS1*:GOSUB 5500:RETURN 
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108 REM PLAYER1 TO PL AY FI ELD 

109 RETURN 

110 30=50+1 :G0SUB ZAP2:PLAYER1*=BUFFER 
*:PLAYER1 % (Y1)=LEGS1$:GQSUB 5500:RETUR 
N 

111 Sl=Sl+5: GOTO 660:REM PLAYER1 HITS 
CRYSTAL 

112 SO-SO+l: GQSUB ZAP2: PLAYER 14>=BUFFER 
$:PLAYER 1$(Y1)=P11MAGE1$:GOSUB 5500:RE 
TURN 

113 RETURN 

114 RETURN 

115 RETURN 

116 SO=SO+l:GQSUB ZAP2:PLAYER1*=BUFFER 
$:PLAYER1 $(Y1)=LEGS1 $:GOSUB 5500:RETUR 
N 

117 REM MISSILE 0 TO PL AYFI ELD 

118 RETURN 

119 FIRE0=0:GOSUB OFF:MX0=0:RETURN 

120 FIRE0=0:GOSUB OFF:MX0=0:POKE HITCL 

r,o:so=so+i:goto 660:rem missile hits 

CRYSTAL / 

121 RETURN 

122 RETURN :GOSUB ZAP2:RETURN 

124 REM MISSILE 1 TO PLAYFIELD 

125 RETURN 

126 FIRE1=0:GOSUB OFF:MX 1=0:RETURN 

127 FIRE0=0:GOSUB OFF:MX 1=0:POKE HITCL 
R,0:S1=S1+1:G0T0 660:REM MISSILE HITS 

CRYSTAL/ 

128 RETURN 

129 RETURN :GOSUB ZAP:RETURN 

130 REM MISSILE 1 TO PLAYER 0 

131 RETURN 

132 gosub zap:si=si+i:firei=o:mxi=o:go 

SUB 5500:RETURN 

133 RETURN 

134 RETURN 

135 GOSUB 85:RETURN 

136 REM MISSILE 0 TO PLAYER 1 

137 RETURN 

138 RETURN 

139 gosub 53.o:so=so+i:fireo=o:mxo=o:go 
SUB 5500:RETURN :REM MO HITS PLAYER1 
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140 RETURN 

141 RETURN 

142 RETURN 

170 MISSILES$=BUFFER*:D0=0:D1=0:RETURN 

:rem erase missile and sound 

199 REM MAIN LOOP 

200 GOSIJB PEEK (F'OPF)+100: GOSUB PEEK (PI 
PF)+109:GOSUB PEEK(MOPF)+118:GOSUB PEE 
K(M1PF)+125 

201 GOSUB PEEK(MlPL)+131:GOSUB PEEK(MO 
PL)+137 

202 POKE HITCLR,1:Y1A=Y1:X1 A=X1:XOA=XO 
:YOA=YO:REM clear collision register/ 
SAVE PLAYER COORDINATES 

203 GOSUB PEEK(JO):GOSUB PEEK(J1>+11:P 
OKE HPOSPO,XO:POKE HP0SP1,X1:REM . 

ADJUST COORDINATES/POKE HOR. POSITION 
S 

204 IF PEEK(JO)015 THEN Z=Z+l:GOSUB 3 
4+Z:G0T0 206:REM MODE LEGS 

205 PLAYEROS(YO)=LEGS1* 

206 IF PEEK(Jl)015 THEN W=W+1:GOSUB 5 
4+W:GOTO 210:REM MODE LEGS 

207 PLAYER1*(Y1)=LEGS1* 

210 IF PEEK(RANDOM)>220 THEN IF X0>142 
AND Y0<34 OR XI>142 AND Yl<34 THEN GO 
SUB 450 

299 REM MISSILE MODE ROUTINE 

300 POKE SIZEM,PEEK(RANDOM):POKE SDO,P 
o:poke DVO,DO:POKE SD1,PI:POKE DO1,DO 

301 IF PEEK(BUTTONO)=0 AND PEEK(J0)<>1 
5 THEN MOVEO=F'EEK (JO) : FI REO=F IREO+1 

302 IF PEEK (BUTTON 1) =0 AND PEEK. (Jl)Ol 
5 THEN M0VE1=PEEK(J1):FIRE1=FIRE1+1 
305 IF FIRE0=0 AND FIRE1=0 THEN 200 
307 POKE HP0SM0,MX0:P0KE HP0SM1,MX1 
315 IF FIRE0=1 THEN MX0=X0+3:MY0=Y0+7: 
DIRO=MOVEO:FIREO=FIRE0+1: DO*15:REM SET 
INITIAL POSITION OF MISSILES 

317 IF FIRE1=1 THEN MXl=Xl+3:MYl=Yl+7: 
DIR1=MOVE1:FIRE1=FIRE1+1:D0=15 

320 IF FIREO>1 THEN GOSUB DIR0+60 

321 IF FIRE1>1 THEN GOSUB DIR1+80 
330 DO=DO—2:IF DOC 1 THEN D0=0 
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335 IF MY0=MY1 THEN 400 

340 MISSILES*=BUFFER*:MISSILES*(MYO)=M 

IMAGE©*:MISSILES*(MY 1 )=MIMAGE1* 

399 GOTO 200 

400 MISSILES*=BUFFER*:MISSILES*(MYO)=B 
MISS*:GOTO 200:REM IMPORTANT: TURN ON 
BOTH MISSILES 

450 FOR 1=15 TO 1 STEP -1:VT=PEEK(RAND 

OM)/2.7:SOUND 3,I,4,15:COLOR 1:PLOT 13 

2,16:DRAWTO 90, VT 

455 PLOT 132,16:DRAWTO 159,VT 

460 COLOR O: PLOT 132, 16: DRAWTO 90,VT:F' 

LOT 132,16:DRAWTO 159,VT:NEXT I:SOUND 

3,0,0,0:GOSUB 700:RETURN 

499 GOTO 200 

500 GOSUB OFF:MX 1=0:POKE MOPL,l:POKE M 

ipl,2:fireo=o 

510 POKE DV0,0:P0KE SD1,0:F0R 1=2 TO 2 
55 STEP 2:POKE 704,I:SOUND O,I,14,14:N 
EXT I:POKE 704,KOLORO 

520 X0=50:YO=78:POKE 53248,XO:PLAYERO* 
=BUFFER*:PLAYERO*(YO)=LEGS1*:RETURN 
530 GOSUB OFF: MX0=0: POKE M1F'L,1:F’0KE M 
OPL,2:FIRE1=0:FIRE0=0 

540 POKE DVO,0:POKE SD1,0:FOR 1=2 TO 2 
54 STEP 2:POKE 705,I:SOUND 0,I,14,15:N 
EXT I:POKE 705,K0L0R1 

550 X 1 =62: Y1 =78: PLAYER 1 *=BUFFER*: F'LAYE 
R1*(Y1)=LEGS1*:POKE HP0SP1,X1 
560 RETURN 

600 TRAP 610:FOR 1 = 1 TO 128:? I;"= "5 A 
SC(BMISS*(I)):NEXT I:STOP :REM GO HERE 
TO LOOK AT DATA IN PM MEMORY. 

610 END 

660 FOR J=1 TO 20:FOR 1=1 TO 5:SETC0L0 
R 4,J,J+l:SOUND 0,1*10-7,10,1*2:NEXT I 
:NEXT J:POKE M0PL,2:P0KE MlPL,2 

661 PLAYER1*=BUFFER*:PLAYERO*(YO)=LEGS 
1*:XI=62:Y1=78:POKE 53249,XI:ROUND=ROU 
ND+1 

662 X0=50:Y0=78:GOSUB 5500:PLAYERO*=BU 
FFER*:PLAYERO*(Y0)=LEGS1*:POKE 53248,X 
0:SETCOLOR 4,HUE,LUM:RETURN 
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700 REM CRYSTAL 

710 COLOR 2:PLOT 131,15:DRAWTO 137,15: 

PLOT 134,12:DRAWTO 134,18 

720 PLOT 131,12:DRAWTO 137,18:PLOT 131 

,18:DRAWTO 137,12:COLOR 1 

730 RETURN 

900 REM 

910 REM 

920 REM 

1900 PLAYER0*=BUFFER1;: Y0=128: X0=80: X=0 
:GOTO 190 

2000 GOSUB 10000:REM INITIALIZE 
CONSTANTS 

2005 GRAPHICS 7:REM GR.MODE BEFORE PNG 

2007 GOSUB 12000:REM BRAN PLAVF1ELB 
2010 GOSUB 11000:REM PMGSETUP 
2030 GOSUB 13000:REM SCREEN POSITION 
2040 GOSUB 5000:REM SELECT COLOR 
2050 RETURN 

2080 IF MY1<1 OR MY1>128 THEN MYl=i:PO 
KE 53253,0:FIRE1=0:SP=3:GOTO 2100 
2085 IF MX1<0 OR MX 1>150 THEN MX1=10:F 
IRE1=0:GOTO 2100 

2087 IF MXOCO OR MX0>150 THEN MX0=10:F 
IRE1=0:GOTO 2100 

2090 IF MYO<1 OR MY0>128 THEN MYO=YO:P 
OKE 53252,0:FIRE0=0:GOTO 2100 
2095 IF MY1<1 OR MY1>128 THEN MY1=Y1:P 
OKE 53252,0:FIRE0=0:GOTO 2100 

2099 ? "GOOF NO. ";PEEK(195);"SEE LINE 
NUMBER " 5 PEEK (18<b) +256*PEEK (187) 

2100 D0=0:TRAP 2080:GOTO 200:REM PEEK( 
187)*256+PEEK(186) 

3000 IF X0>210 THEN X0=210:REM CORRECT 
PLAYER COORDINATES 
3010 IF X0<39 THEN X0=39 
3020 IF Y0<1 THEN Y0=1 
3030 IF Y0>128 THEN Y0=128 
3040 MX0=0:MYO=YO:MX 1=0:MY 1=Y1 
3050 D0=0:D1=0:REM TURN OFF MISSILE 
SOUND 

3060 FIRE0=0:FIRE1=0:REM TURN OFF FIRE 
FLAG 
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3070 z=o:rem reset leg movement 
COUNTER 

3080 TRAP 3000:GOTO 210 
4000 RETURN :POKE 20,0 
4050 ? CHR*<125):? " 

5 11-Y:SOUND 0,Y+PEEK(20)+5,14,10:GOTO 
4010 

5000 ? "PRESS SELECT TO CHANGE SCREEN 
COLOR, OPTION TO CHANGE PLAYER COLOR, 
START TO START GAME" 

5005 X0-50:X1=62:POKE HPOSPO,XO:POKE H 
F'OSPl, XI 

5015 IF PEEK(53279)=5 THEN GOSUB 5200 
5020 IF PEEK(53279)=3 THEN GOSUB 5300 
5025 IF PEEK(53279)=6 THEN SETK=SETK:R 
ETURN 

5030 GOTO 5015 

5199 REM CHANGE SCREEN COLORS 

5200 LUM=LUM+1 

5210 IF LUM>14 THEN LUM=0:HUE=HUE+1 
5220 IF HUE>15 THEN HUE=0:LUM=0 
5230 SETCOLOR 4,HUE,LUM 

5299 REM CHANGE PL AVER COLOR 

5300 K0L0R0=K0L0R0+2:KOLOR1=KOLOR1+2:1 
F KOLORO>254 THEN K0L0R0=0 

5305 IF KOLOR1>254 THEN KQL0R1=0 

5310 POKE 704,KOLORO:POKE 705,K0L0R1:R 

ETURN 

5500 ? CHR$(125):? " ROUND # 

ROUND:? :? "PLAYER l = ";so;" 

PLAYER 2 = "Ssi:SOUND 0,255,14,15 
5510 IF SO>9 THEN ? :? "PLAYER 1 WINS" 
:GOTO 5540 

5520 IF SI>9 THEN ? :? "PLAYER 2 WINS" 
:GOTO 5540 
5530 RETURN 

5540 POP :? :POKE 82,0:? "PRESS THE FI 
RE BUTTON FOR ANOTHER GAME";:SOUND 0,0 
,0,0:SOUND 1,0,0,0 

5550 IF PEEK(BUTTONO)=0 THEN 5560 
5552 IF PEEK(BUTTON1)=0 THEN 5560 
5555 GOTO 5550 
5560 POKE 82,2:RUN 
10000 KOLORO=163:KOLOR1=83 
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10020 X0=52:Y0=78:SP=3:X1=67:Y1=78:MXO 
=6:MY0=61:M X1=0:MY1=71:M0PL=53256: SDO= 
53760:DV0=53761:SD1=53762: DV1=53763 
10025 P0=50:PI=53 

10030 REM POKE 53248,XO:PLAYERO*«Y0)=L 
EOS1$:POKE 53249,X1:PLAYER1$(Y1)“LEGS1 
* 

10040 POKE 53252,0:POKE 53253,X1+3 
10050 J 0=632:J1=633:HP0SP0=53248:HPOSP 
1=53249:HP0SM0=53252:HPOSM1=53253:BUTT 
0N0=644 

10055 BUTTON1=645:MS0=8 
10060 RAND0M=53770:SIZEM=53260 
10100 HITCLR=53278:POKE 53278,1:P0PF=5 
3252:P1PF=53253:M0PL=53256: M0PF=53248: 
M1PL=53257:M1PF=53249 

10110 PRI0R=623:R0UND=1:DIM STRING*<12 
8):ZAP=500:ZAP2=530:0FF=170 
10200 POKE HITCLR,1:REM CLEARS 
COLL ISIOC REGISTERS 
10998 RETURN 

11000 DIM FILLER1$(1),FILLER2*((INT(AD 
R(FILLER1$)/1024)+1)*1024-ADR(FILLERl* 
) -1 ) 

11010 DIM BUFFER*(384),MISSILES*(128), 
PLAYERO*<128),PLAYER1*(128),PLAYER2*(1 
28),PLAYER3*(128) 

11020 BUFFER*=CHR*(0) 

11030 BUFFER*(384)=CHR*(0) 

11040 BUFFER*(2)=BUFFER* 

11045 MISBILES*=BUFFER*:PLAYERO*=BUFFE 
R*:PLAYER1*=BUFFER*:PLAYER2*=BUFFER*:P 
LAYER3*=BUFFER* 

11050 DIM LEGS1*(17),LE8S2*(17),LEGS3* 

(17) 

11055 RESTORE 11300 

11060 FOR 1=1 TO 17:READ A:LEGS1*(I,I) 
=CHR*(A):NEXT I 

11065 FOR 1=1 TO 17:READ A:LEGS2*(1,1) 
=CHR*(A):NEXT I 

11067 FOR 1=1 TO 17:READ A:LEGS3*(1,1) 
=CHR*(A):NEXT I 

11069 DIM MIMAGEO*(1):MIMAGEO*=CHR*(3) 
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11070 DIM MIMAGEl*(1):MIMAGE1$=CHR*(12 
) 

11071 DIM BMISS*<1):BMISS$=CHR$(15):RE 
M BOTH MISSILES "ON " 

11072 POKE 704,KOLQRO:REM SET COLOR OF 
PLOYERO 

11075 POKE 705,KOLQR1:REM COLOR PLOVER 
1 

11080 POKE 54279, ADR (BUFFER*) /256: REM 

SPECIFY STORT OF PM MEMORY 

11085 POKE 559,46:REM DOUBLE LINE RES. 

11090 POKE 53277,3:REM TURN ON PMG 
11100 POKE 53260,5:REM NIDTH/MISSILES 
11110 POKE PRIOR,2:REM SETS PRIORITY 
REGISTER 

11120 POKE HITCLR,1:REM CLEOR 
COLLISION REGISTERS 
11290 RETURN 

11300 DATA 0,0,0,28,28,8,28,58,89,24,6 
0,36,36, 102,0,0,0 

11310 DATA 0,0,0,28,28,8,28,58,89,24,4 
0,76,68,68,0,0,0 

11320 DATA 0,0,0,28,28,8,28,58,89,24,5 
6,72,132,130,0,0,0 

11330 DATA 0,0,0,120,56,16,56,116,176, 
48,50,60,64,192,0,0,0 

11999 REM DRON PLOYFIELD 

12000 POKE 752,1:SETCOLOR 4,7,6 

12005 ? " MOZEDUEL" 

12010 COLOR l:PLOT 0,0:DRAWT0 159,0:DR 

AWTO 159,79:DRAWTO 30,79 

12015 COLOR 3:DRAWTO 0,79:DRAWTO 0,60: 

REM STORTING BOX 

12017 COLOR l:DRAWTO 0,0 

12020 PLOT 80,61:DRAWTO 80,79 

12025 COLOR 3:PLOT 1,60:DRAWTO 30,60:D 

RAWTO 30,78:COLOR 1:REM STORTING BOX 

12030 PLOT 52,60:DRAWTO 52,45:DRAWTO 1 

10,45:DRAWTO 110,60:DRAWTO 137,60:DRAW 

TO 137,45:DRAWTO 110,45:PLOT 159,32 

12040 DRAWTO 110,32:PLOT 80,45:DRAWTO 
80,20 

12041 GOSUB 700:REM DROM CRYSTOL 
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12050 PLOT 43,0:DRAWTO 43,30:PLOT 52,4 
5:DRAWTQ 22,45:DRAWTO 22,13:PLOT 108,0 
:DRAWTO 108,17:POKE 559,34:RETURN 
13000 X0=0:X1=0:REM horiz.plover pos. 
13010 V0=78:REM VERTICAL PLAYER POS. 
13015 Vl=78 

13020 POKE 704,KOLORO:POKE 705,K0L0R1: 
REM INITIAL COLOR 

13025 POKE M0PL,0:P0KE M1PL,0:REM SET 
N1DTH OF PLAYERS 

13030 POKE 53248,XO:POKE 53249,XI:REM 
SET HORIZONTAL POSITION OF PLAYERS 
13040 PLAYER0*(Y0)=LEGS1$:REM PUT DATA 
IN PM MEMORY 

13045 PLAYER1*(Y1>=LEGS1$:REM PLAYER2 
13050 RETURN 
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Great! You've mastered the fundamentals of PMG and have seen how it can be 
used to develop a two-player, arcade-style game. In this chapter you'll learn 
some additional programming kinks. 

FIVE PLAYERS! 

So far I've said that you can create up to four players and that each player has a 
missile. Well, as you'll soon see, it's possible to have five players. 

There is a trade-off, though; you have to give up all of your missiles. In 
other words, if you want, you can use the missile memory area as a fifth player. 
To do that you simply add 16 to the value you would normally poke into the 
priority register. 

Using the Priority Register. Remember the priority register? It is location 623. 
You set various display priorities by poking either a I, 2, 4, or 8 into location 623. 
[To review, see "Setting Display Priorities" in Chapter 5.) 

Suppose you want all players to appear in front of all playfields. To set up 
this display priority, you would normally poke a 1 into location 623. But if you 
want to turn the missiles into a fifth player, you would poke 17 into 623 (1+16). 


153 
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To help you keep track of what you're doing you might want to write the code 
like this: 

PRIOR=623 
POKE PRIOR,1+16 


■ Suppose you want your normal player (players 0 through 3) to appear 
behind all playfields. The usual practice would be to poke 4 into location 
623. But suppose you want a fifth player. Assuming PRIOR is initialized to 
623, how would you code this? 


ANSWER 

POKE PRIOR.4+16 (or POKE PRIOR,20) 


Setting the Fifth Player's Color. To specify the color you want for the fifth 
player, poke a number from 0 to 254 into location 711. (To review, see "Specify¬ 
ing Player Color" in Chapter 4.) 

Moving the Fifth Player. Although some PMG programmers may have 
problems with vertical movement, it will be easy for youl Just use the same 
method you learned earlier. Here's an example: 

MISSILES$(Y4) = LEGS1$ 

This statement will cause the image contained in LEGS1S to appear on 
the screen at whatever vertical location is specified by Y4. (Remember Y0 goes 
with player 0, Y1 with player 1, Y2 with player 2, and so on. Remember, too, that 
the fifth player is called Player 4.) 

Horizontal Movement. Horizontal movement of the fifth player is not so 
easy. Each missile still keeps its own horizontal position register. So to move the 
fifth player horizontally (in one piece) you have to poke all four horizontal 
position registers. Assuming that you have all missiles set to normal width, you 
might do it like this: 

POKE HPOSMO.X4 
POKE HPOSM1.X4+2 
POKE HPOSM2.X4+4 
POKE HPOSM3.X4+6 
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All those POKEs add up and slow down the animation loop. So here's another 
case where a machine language routine might come in handy, but that's the 
subject of my next book. 

Even though these separate horizontal position registers pose a speed 
problem, you still might use them to good effect. For example, you might 
"blow up" the fifth player and scatter his pieces all over the screen. Or you 
might mysteriously create the fifth player by gradually moving his various 
pieces together. 

Collision Detection. Another consideration is collision detection. Each mis¬ 
sile still has its own collision detection register. That could be interesting. For 
example, you might specify that your player is vulnerable only if he is hit in the 
right arm. (He couldn't be hit by a missile, of course, but he might be hit by a 
"laser" created with a DRAWTO statement. Or he might be hit by another 
player.) 


MULTICOLORED PLAYERS 

So far each player has only one color. But ifyou want, you can overlap player 0 
with player 1 (or player 2 with player 3). In the area of overlap, a third color will 
be produced. In effect, then, you can have a three-colored, animated object. To 
make this work, you must first add 32 to the value that you would otherwise 
poke into the priority register (location 623). 

■ Let's try a problem to clarify that. Suppose you want your players to have 
priority over playfields. Normally, you'd poke 1 into 623. But let's say you 
want a fifth player and you also want to combine player 0 and player 1 to 
create a multicolored spaceship. How would you code the poke into 
location 623? 


ANSWER 

POKE 623,1+16+32 (or POKE 623,49) 


GRAPHIC SHAPE REGISTERS 

Now let's turn to another topic: the graphic shape registers. So far we haven't 
needed these registers. That's because we allocated a special area in memory 
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to contain the PM shape data. And as you will recall, we told ANTIC where this 
PM memory area was by poking the address of BUFFER into location 54279. 
(To review, see "PMBASE" in Chapter 4.) 

Also, we set up what is called "direct memory access" by poking location 
559 with an appropriate value. In addition, we specified the type of resolution 
we wanted by poking location 53277. 

Well, if you use the graphic shape registers, you can bypass ANTIC, and 
you don't have to poke anything into locations 54279, 559, or 53277. Conse¬ 
quently, your PMG setup is greatly simplified. 

But the graphics shape registers are not so great for animation. That's 
because each can contain only one byte of data. They are useful, though, 
when you want to display a player image the entire length of the screen. You 
might want to do this to highlight textual material or to create a special 
boundary for a playfield. 

Here are the graphics control registers for each of the players: 

Player Number Location 

0 53261 

1 53262 

2 53263 

3 53264 

The graphics shape register for all of the missiles is at location 53265. 
Even though each graphics shape register holds only one byte of image data, 
that byte runs the entire length of the screen. You'll see an example of these 
registers in action in a moment, but first I'd like to expand on DMACTL, the 
direct memory access control register at location 559. 


DMACTL 

You can specify different options using this register. In the chart below, just add 
up the options you want. Then poke the total into location 559. But note that 
you must pick only one of the first four options: 

Value to Poke 

Option into 559 

No playfield.0 

Narrow playfield . 

Standard playfield 
Wide playfield ... 


1 (pick one) 
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Missiles .4 

Players.8 

Single-line resolution .16 

Double-line resolution.32 


Note: you won't be able to see the edges of the wide playfield unless 
you scroll off the usual screen. 

SAMPLE PROGRAM 

As usual I will end this chapter with a sample program. The program illustrates 
the use of: 

PMG in graphics mode 0 
The fifth player 
Priority selection 
Playfield size selection 

Overlapping of players to get multicolored objects 
A simplified PMG setup (using the graphics shape registers) 

If you have written programs in graphics 0. you may want to consider 
spicing them up with some of the techniques demonstrated in this program. 
Happy hacking! 


1 GOTO 4 

2 SAVE "D:GRAFF.SAV":STOP 

4 ? CHR$(125):REM CLEAR SCREEN 

5 POKE 752,1:REM TURN OFF CURSOR 

7 GOSUB 500:REM SIMPLIFIED PMG SETUP 
10 POSITION 2,10:? "In this example," 
20 ? "we are NOT using" 

25 ? "ANTIC or Direct" 

30 ? "Memory Access" 

32 ? "to -fetch Players " 

33 ? "or Missiles." 

35 GOSUB 900:REM Wait for user to pres 
s a key. 

36 ? CHR$ (125) : REM CLEFtR SCREEN 

40 POSITION 24,9:? "Notice how easy" 

42 POSITION 24,10:? "it. is to add " 
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44 POSITION 24,11:? "Color to " 

46 POSITION 24,12:? "Graphics Mode O." 

50 DELAY=3O0:G0SUB 700:REM PAUSE FOR A 
MOMENT 

60 POSITION 24,16:? "Like this!":DELAY 
=50:60SUB 700 

62 POKE 53248,176:POKE 53249,144:REM P 
UT PLAYERS ON SCREEN 
65 DELAY=100:GQSUB 700 
70 POSITION 24,18:? "It’s also easy" 

80 POSITION 24,19:? "to change that" 

81 POSITION 24,20:? "color.":DELAY=200 
:GOSUB 700 

85 FOR 1=0 TO 254 STEP 10: X=5-'"3: POKE 7 
04,I:POKE 705,I:NEXT I:REM X=5 A 3 is ad 
ded hare simply to add a pause 
90 POKE 704,80:POKE 705,80 
100 GOSUB 700 

102 ? CHR*<125):POSITION 2,3 

105 ? "And it’s easy to" 

106 ? "go back to the regular" 

107 ? "play-field color." 

108 GOSUB 900 

110 POKE 53248,0:POKE 53249,0:REM MOVE 
PLAYERS OFF SCREEN 
115 GOSUB 700 

117 ? CHR$(125):? :? :POSITION 2,3 
120 ? "You can also -fill" 

125 ? "the entire screen" 

130 ? "with all 5 players." 

135 DELAY=400:GOSUB 700 

140 ? : ? "Like so: " : X = X -'3 

150 GOSUB 1000:REM MOVE ALL 5 PLAYERS 

ONTO SCREEN 

230 GOSUB 700:? CHR$(125):POSITION 2,3 

232 ? "The play-field is now hiding" 

234 ? "behind the players. "'.7 :? 

235 DELAY=250:GOSUB 700 

236 ? "Now I’ll put it in front" 

238 ? "of the players." 

239 DELAY=100:GOSUB 700:POKE 623,4+16 

240 DELAY=500:GOSUB 700:? CHR*(125):PO 
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SITION 2,10:? "Next, when you press a 
key, " 

241 ? "I’ll shrink the play-field" 

242 ? "for a moment by poking ":? "Loc 
ation 559 with 33." 

243 GOSUB 900:? CHR$ (125) : POKE 559,1+3 
2:DELAY=200:G0SUB 700:P0KE 559,2+32 

244 ? :? :? "Next, let’s set each play 
er " 

245 ? "to a different color." 

246 GQSUB 900:POKE 559,2+32 

247 POKE 704,16:POKE 705,64:POKE 706,9 
6:POKE 707,144:POKE 711,192:REM SET PL 
AYERS TO DIFFERENT COLORS 

248 ? CHR$(125):GOSUB 700 

250 POSITION 2,3:? "Notice that player 
s " 

252 ? "0-3 are behind the playfield" 

254 ? "but Player 4 (at right)" 

255 ? "is in front of the playfield." 
260 GOSUB 900 

265 ? CHR$(125):POKE 623,4+16:REM SET 
PRIORITIES AND ENABLE 5TH PLAYER 
270 POSITION 2,3:? "As you can see, PI 
ayer 4" 

272 ? "(the one made up of missiles)" 
274 ? "always displays in front of" 

276 ? "all playfields.":GOSUB 900:? CH 
R$<125) POSITION 2,3 

277 ? "Let’s get rid of the ":? "playf 
ield again.":GOSUB 900:? CHR*(125):POK 
E 623,1+16:POSITION 2,9 

278 ? " Playfield now hiding.":GOSUB 
900 

280 ? CHR$(125):POKE 623,4+16:POSITION 
2,3 

282 ? "In conclusion, here’s an" 

283 ? "example of how you can" 

284 ? "overlap players to create" 

286 ? "a multicolored object." 

290 GOSUB 900:? CHR$(125> 

292 POKE 623,1+16+32:REM SET PRIORITY , 
ENABLE 5TH PLAYER, CREATE MULTICOLORED 
OBJECT NHEN PLAYERS OVERLAP 
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299 REM SET PLAYERS 0 AND 1 TO OVERLAP 

300 POKE 53248,48:REM PLAYER 0 
310 POKE 53249,48+16:REM OVERLAP 
320 POKE 53250,0:REM MOVE OFF SCREEN 
350 POKE 53251,0 

360 POKE 53252,0 
370 POKE 53253,0 
380 POKE 53254,0 
390 POKE 53255,0 

400 POSITION 18,10:? "The three colors 

410 POSITION 18,11:? "at le-ft were " 
420 POSITION 18,12:? "produced by" 

425 POSITION 18,13:? "Players 0 & 1." 
430 POSITION 18,15:? "You can use the" 

432 POSITION 18,16:? "same idea to" 

434 POSITION 18,17:? "make a multi-" 
436 POSITION 18,18:? "colored flying" 
438 POSITION 18,19:? "spacecraft!" 

440 POSITION 18,22:? " END OF PROGRAM" 

499 GOTO 499 

500 POKE 623,1+16:REM DISPLAY PLAYERS 
IN FRONT OF PLAYFIELD , ENABLE 5TH PLAY 
ER 

505 POKE 53256,3:POKE 53257,3:POKE 532 
58,3:POKE 53259,3:REM SET ALL PLAYERS 
TO QUADRUPLE NIDTH 

507 POKE 53260,192+48+12+3:REM SET ALL 
MISSILES TO QUARUPLE NIDTH 
510 POKE 704,80:REM SET PLAYER 0 COLOR 

512 POKE 705,80:REM PLAYER 1 COLOR 
514 POKE 706,80:REM PLAYER 2 COLOR 
516 POKE 707,80:REM PLAYER 3 COLOR 
518 POKE 711,80:REM PLAYER 4 COLOR 

559 REM POKE DATA DIRECTLY INTO THE T 
HE PLAYER GRAPHIC REGISTERS 

560 POKE 53261,255:REM IMAGE FOR PLAYE 
RO 

570 POKE 53262,255:REM PLAYER1 
575 POKE 53263,255:REM PLAYER 2 
580 POKE 53264,255:REM PLAYER 3 
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582 POKE 53265,255:REM PLOVER 4' 

699 RETURN 

700 FOR 1=1 TO DELAY:NEXT I 
710 RETURN 

800 IF PEEK(764)0255 THEN POKE 764,25 
5:RETURN 
810 GOTO 800 

900 POSITION 2,22:? "TAP ANY KEY":? "T 
0 CONTINUE":GOSUB 800 

910 POSITION 2,21:? " ":? 

920 RETURN 

999 REM MOVE OLL PLOVERS ON SCREEN 

1000 POKE 53248,48:REM NOR. POS. PO 
1010 POKE 53249,48+32 

1020 POKE 53250,48+2*32 
1030 POKE 53251,48+3*32 
1040 POKE 53252,48+4*32 
1050 POKE 53253,48+(4*32)+8 
1060 POKE 53254,48+(4*32)+16 
1070 POKE 53255,48+(4*32)+24 
1080 RETURN 
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Player Color Location 

Location 

704 

705 

706 

707 
711 

A guide for designating your player's color: 


Player 

0 


4 (missiles) 


Color 


Number 


Gray 0 

Gold 16 

Orange 32 

Red 48 

Pink 64 

Violet 80 

Purple 96 
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Blue 112 

Blue 128 

Light Blue 144 

Turquoise 160 

Blue-Green 176 

Green 192 

Yellow-Green 208 

Orange-Green 224 

Light Orange 240 


These numbers are starting numbers. To any given number you can add 
an even number from 0 to 14 to change the lightness of the color. 


Player Missile Memory 

To tell ANTIC where the start of PM memory is we simply poke the proper 
address into location 54279, the player-missile base register. Example: 

POKE 54279,ADR(BUFFER$) 


Location 559, DMACTL 

Choose the options you want and add up their values. Poke the total into 559. 


Option Value 

No playfield 0 

Playfield size: 

Narrow 1 

Standard 2 

Wide 3 

Turning on: 

Missiles only 4 

Players only 8 

Missiles and players 12 

Single-line resolution 16 

Double-line resolution 0 

Turn on DMA 32 
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Location 53277, The Graphics Control 
Register (GRACTLJ 

Use this location along with 559 to "turn on" the PMG system. 

If you want: Then: 

Missiles only Poke 53227,1 

Players only Poke 53277,2 

Players and Missiles Poke 53277,3 

Horizontal Position Registers 

Location Player 

53248 

53249 

53250 

53251 

Location Missile 

53252 

53253 

53254 

53255 

Horizontal Coordinates 


o 

1 

2 
3 



|| | || 

50 80 120 160 200 


HORIZONTAL 

COORDINATES 
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Joystick Reading 

Peek into these locations to read joystick values. 

Location Joystick Number 

632 0 

633 1 

634 2 

635 3 

Joystick Values 

This diagram shows the values produced when you move the joystick in 
various directions. Note that if you do not move the joystick, a value of 15 is 
produced. 



Sound Registers 

Location Used to Control 

53760 Pitch of voice 0 

53761 Distortion and volume of voice 0 

53762 Pitch of voice 1 

53763 Distortion and volume of voice 1 

53764 Pitch of voice 2 

53765 Distortion and volume of voice 2 







53766 

53767 


Player Collisions / 167 


Pitch of voice 3 

Distortion and volume of voice 3 


53768 Pitch of all voices 

Note: before using pokes to create sound, initialize the sound system 

with: 

POKE 53768,0 
POKE 53775,3 

(Or simply code: SOUND 0,0,0,0) 

Location 53768 can be used to control the quality of sound. For example, 
you can filter out certain frequencies or combine two channels to improve pitch 
range and accuracy. See the book De Re Atari for details. (Available from Atari 
Program Exchange.) 

Missile Collisions 

Memoiy Location 

53248 

53249 

53250 

53251 

53256 

53257 

53258 

53259 

Player Collisions 

Location Collision Shown 

53260 Player 0 to player 

53261 Player 1 to player 

53262 Player 2 to player 

53263 Player 3 to player 

53252 Player 0 to playfield 

53253 Player 1 to playfield 

53254 Player 2 to playfield 

53255 Player 3 to playfield 


Shows: 

Missile 0 to playfield collision 
Missile 1 to playfield collision 
Missile 2 to playfield collision 
Missile 3 to playfield collision 
Missile 0 to player collision 
Missile 1 to player collision 
Missile 2 to player collision 
Missile 3 to player collision 
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Location 53278, Hit Clear Register 

To clear all collision registers, poke a 1 into HITCLR (location 53278). 

Location 623, Priority Register 

Display Priority Value to Poke into 623 

All players in front of all playfields. 1 

Players 2 and 3 behind playfields; 
players 0 and 1 in front of 

playfields. 2 

All playfields in front. 4 

Players in front of some play- 
fields, but behind others. 8 

Suggestion: Experiment! Move your players over various playfield objects 
to discover the effect of various priority settings. 

Other Options for Location 623 

Pick the desired options and add up the values. Poke the total into location 623. 

Option Value 

Combine missiles to make a 5th player. 16 

Overlap players to make a third color. 32 

Graphics Shape Registers 

Player Number Location 

0 53261 

1 53262 

2 53263 

3 53264 
53265 


All missiles 
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$14.95 


ATARI® Home Computers have a secret feature that 
sets them apart from other personal computers. l\low 
you can«find out all about this secret feature and how 
to use it. It’s called player-missile graphics—with it you 
can create all kinds of special effects! It has many excit¬ 
ing features that not only will make game programming 
easy, but also will make other types of programs— < 

educational, business, etc.—more interesting and entec- 
taining. Player-missile graphics will enable you to 
custom-design graphic images, make them any color 
you want, change their size, move them independently of - 
each other, and even create sound to accompany your 
graphics “players”! For example, in a music program 
you could use players for notes and have them dance 
across the screen along with the music. ATARI Player- 
Missile Graphics will take you step by step through all 
this and more. You’ll find out everything you need to 
know to create sophisticated graphic effects far beyond 
the reach of most personal computers. 





